Пост Лукацкого

26 September 2025 11:34

Если резюмировать последнюю нормативку Поднебесной 🇨🇳 в части уведомления об инцидентах и сравнить ее с другими государствами, то мы увидим, что Китай вводит самый "жесткий по часам" режим для тяжелых инцидентов (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

Пост Лукацкого

25 September 2025 19:29

В штаб-квартире ЦРУ 🇺🇸 в Лэнгли стоит известная скульптура Криптос с 4-мя зашифрованными сообщениями, три из которых были разгаданы, а вот 4-е, с момента открытия памятника 3 ноября 1990 года, так и остается неразгаданным. По поводу разгадки зашифрованного послания, автор скульптуры, Джим Санборн, ранее рассказывал, что им были приняты все необходимые меры, чтобы даже его смерть не позволила никому раскрыть полный секрет Криптоса, так как нет ни одного человека, который бы знал полное решение загадки. Он также заявил, что даже он не знает полного решения.

Но вот совсем недавно Санборн сообщил в своем письме в The Washington Post, что его все достало и он устал ждать готов выставить разгадку 🔑 4-го сообщения на аукцион, надеясь, что покупатель все-таки оставит разгадку в секрете, что сохранит ореол таинственности над Криптосом. А пока желающие, включая и подписчиков, пытаются самостоятельно разгадать 35-тилетнюю загадку. Может и вы попробуете?.. 🤔

#криптография #искусство

Пост Лукацкого

25 September 2025 11:34

Финансовый регулятор Сингапура 🇸🇬 подготовил документ по рискам, связанным с дипфейками. Простенько и со вкусом – описаны основные риски (обход биометрической аутентификации, социальный инжиниринг и дезинформация), даны реальные примеры реализации этих рисков и даны рекомендации (не требования), как бороться с этим 🎭

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

Пост Лукацкого

24 September 2025 19:45

💡 Идея нового мероприятия по антикризисным мероприятиям в ИБ. Оно начинается с регистрации, где каждому участнику со стороны заказчика вручается футболка с одной из двух надписей "Я бдю! Мы бдим! А ты бдишь?" или "Я бздю! Мы бздим! А ты бздишь?". И сразу всем понятно, кто стесняется признаваться в произошедшем у него инциденте, а кто нет. В конце мероприятия так и не распакованная коробка с футболками с первой надписью уезжает на склад до следующего года. Тем, кому не хватило футболок со второй надписью обещают прислать ее курьером 👕

ЗЫ. Чтобы пост был не просто хиханьки-хаханьки, поучаствуйте в опросе у Ники про наличие антикризисного плана коммуникаций на случай инцидента ИБ. Вам всего пару кликов, а отрасли статистические данные 📊

#юмор #антикризис

Пост Лукацкого

24 September 2025 11:34

Видимо так совпало... Вчера днем, в Кибердоме 🏠, обсуждая варианты сотрудничества, всплыла тема с возможными моими встречами перед детьми старших классов и студентов ВУЗов, которые планируют связать свою судьбу с кибербезом. Мол, наставить их на путь истинный, показать перспективу и вот это вот все 👶

Также вчера, но после выступления на Boost'е один из участников спросил меня, какие направления ИБ я считаю наиболее перспективными, так как он среди прочего преподает для детей 👦🏻 старших классов, которые интересуются кибербезом и которых надо направить в нужное русло. А так как выпускниками они станут не раньше 2030-го года, то и направления для них будут не только типовыми (пентесты, ИБ ИИ, ИБ IoT и т.п.), но и более современные (биохакинг, web3 и вот это вот все) 🔮

Наконец, и тоже вчера, мне попалась информация о проводимой в МИФИ Национальной технологической олимпиаде по информационной безопасности для старшеклассников 🏫 Хорошее начинание, как мне кажется. Так что не могу не поддержать коллег и дам ссылку на профиль по ИБ в рамках НТО, а также примеры олимпиадных задач (первая и вторая). Если у вас есть, кому отправить эти ссылки, то не стесняйтесь 🤝 Детей, идущих в ИБ, надо поддерживать!

ЗЫ. Надо будет обновить мою презентацию, которую я перед студентами МФТИ читал – готовить новое поколение ИБшников.

#обучение #работа

Пост Лукацкого

23 September 2025 19:39

Сегодня я выступал на Boost, конференции для диджитал-агентств и студий, занимающихся веб-разработкой 🖥 Времени было не так и много, всего 45 минут (но все равно не уложился, но был крайним и поэтому некритично). Так что пробежался крупными мазками по тому, что важно учитывать руководителям разработки и проектов (было специально объединено два потока, которым важна тема кибербезопасности), и почему от заказчиков все чаще и чаще возникают вопросы кибербезопасности к своим подрядчикам 🤔

Ну тут достаточно вспомнить, что последние взломы некоторых российских ИБ-компаний происходили именно через подрядчиков, ведущих сайты вендоров. Все, что хотел рассказать не успел – там только в раскрытие модели зрелости, метрик ИБ для веб-студий, процедуру оффбоардинга (именно off, а не on) и т.п. можно было углубиться на час для каждой из тем. Но может быть еще где-нибудь про это расскажу 🙊

Когда предложили выступить на Boost, сначала думал отказаться; ну где я и где разработчики сайтов 🤐 Потом сел, подумал (полезное действие, кстати) и понял, а кто, если не я. Первый сайт "Информзащиты" я запускал в конце 90-х годов (жаль, на тридцатилетие компании, которой я 8 лет отдал, не позвали, я бы там поностальгировал за бокалом коньяка). Тогда это даже был не сайт, а набор статических html-страниц, а из всей динамики – только крутящийся логотоп, отрендеренный гендиректором в каком-то графическом дизайнере 🎨 Спустя несколько лет был крупный проект по новому сайту Информзащиты, где я уже полноценно руководил проектом, выбирал студии, писал ТЗ и драл разработчиков во все дыры за полный провал сайта с точки зрения ИБ. Третий сайт, который я запускал, был посвящен совместному проекту Cisco и Positive Technologies (была и такая страница в моей истории до выхода в PT) в году, этак, 2008-м. Наконец, а 2021-м я запустил уже целиком свой сайт, а в 2025 его нахрен заблокировали по жалобе кого-то из "добрых" подписчиков. Но ничего, перееду на новую платформу, с новыми знаниями, опытом и впечатлениями. А для чего еще жить, как не ради этого. А на Boost выступил, да 💪 И вроде всем зашло.

#презентация #devsecops

Пост Лукацкого

23 September 2025 15:39

На Postive Tech Day в Новосибирске я рассказывал всякое про прогнозирование 🔮 атак на компании (презентации уже выложили), в том числе и про мониторинг Даркнета, который, при должной реализации, позволяет "предсказать" готовящиеся против вас атаки. Картинка на эту тему как раз из презентации 🤔

#threatintelligence

Пост Лукацкого

23 September 2025 06:40

Продолжим про адекватность требований регуляторики, но на конкретном примере 🙂 Возьмем ГОСТ 57580.1 и требование РЗИ.15 "Обучение, практическая подготовка (переподготовка) работников финансовой организации, ответственных за применение мер защиты информации в рамках процесса защиты информации" или 117-й приказ ФСТЭК с требованием (п.57) "Оценка уровня знаний должна проводиться не реже одного раза в три года или после компьютерного инцидента, произошедшего у оператора (обладателя информации)" 👨‍🏫

В первом случае у нас есть просто требование без указания частоты и способа подтверждения его выполнения 🤷‍♀️ Во втором случае ФСТЭК дает больше вариантов реализации (п.56) мероприятий по повышению уровня знаний и информированности пользователей информационных систем по вопросам защиты информации. Но как будет проверяться реализация обоих требований? 🤔 На поверхности лежит очевидный вариант – тестирование. Как это можно реализовать в условиях нехватки или отсутствия бюджета? Вручную? Ну такое себе, как мы понимаем. И вот один из подписчиков разработал и выложил (за что ему спасибо) в открытый доступ решение для автоматизации внутреннего обучения и тестирования персонала (например, по ФЗ-152) или по 117-му приказу (тесты расширяемы своими темами) 🧑‍💻

Приложение написано на Python/Flask и легко разворачивается в любой инфраструктуре. Ключевые возможности:
➖Полный контроль. Устанавливается на ваш сервер, данные не покидают периметр компании.
➖Встроенный прокторинг. Система отслеживает и логирует подозрительную активность во время тестов – переключение окон, попытки копирования и печати.
➖Поведенческий анализ. Автоматический поиск аномалий в результатах, таких как высокий балл при низкой вовлеченности в учебные материалы.
➖Реестр сертификатов. Автоматическая генерация и хранение уникальных номеров сертификатов для успешно сдавших тест.
➖Готовые конфигурации. Проект включает файлы для быстрой настройки под Nginx, Gunicorn и Systemd.

Очень неплохой вариант для решения... а вот для решения чего? 🤔 По сути мы говорим не о том, как повысить осведомленность пользователей и проверять ее, а о том, как подтвердить факт реализации требования регулятора. Для очень большого числа специалистов это важно, как показал и опрос и комментарии 😶 Но решает ли это задачи ИБ? Чтобы программы обучения и повышения осведомленности несли ценность, они должны эволюционировать – от ежегодной и развтригодной галочки "пройдено" 🫡 к непрерывной и постоянной практике изменения культуры ИБ, поддерживающей конкретный бизнес (поэтому это сложно учесть в нормативке, которая единая для всех).

Если отталкиваться от зрелости программ обучения и повышения осведомленности, предложенный подписчиков проект – это второй уровень, "ориентированный на нормативку", ценность которого только в выполнении требований 🫡 Давайте признаем, что мы все регулярно проходим такие дурацкие тренинги – от пожарной безопасности или охраны труда до антикоррупционной деятельности и защиты персональных данных. И проходим мы их даже не вникая в вопросы ☑️

Первый уровень зрелости программы – это когда никакой программы нет и в помине 👎 На третьем уровне мы управляем ключевыми рисками через целевые изменения в поведении работников и регулярное подкрепление через анализ обратной связи. Именно здесь вы начинаете оценивать не знания в форме тестирования, а производимые (или непроизводимые) пользователями действия (неуведомление об инцидентах, включение MFA там, где это рекомендовано, но не обязательно, использование сильных паролей и т.п.) 🔏

На следующем уровне безопасность встроена в повседневные процессы и процессы и ресурсы обеспечивают долгосрочную историю. Высший уровень – уже не обучение, а культура ИБ выровнена с целями бизнеса и рассматривается как стратегическая составляющая организации 🧐 Тут и ощущение личной ответственности (а не "отвали, это не мое дело"), и доверие команде ИБ, и релевантность форм и форматов обучения и повышения осведомленности процессам, возрастам и половиной принадлежности работников организации и т.п.

#обучение #opensource #регулирование #maturity #awareness

Пост Лукацкого

22 September 2025 15:50

Кстати, о вырубании лесов 🪓 А давайте посмотрим, сколько мы их уничтожаем на бумажную безопасность? Если сложить базовый пакет требований от разных регуляторов по ИБ, которые распространяются на среднестатистическую организацию, то получится около 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. То есть еще несколько городов было обездеревлено для соблюдения бумажной безопасности 🤔

Чувствуете, что вы 🔤🔤🔤🔤🔤🔤 легких задыхающейся планеты?

#регулирование #математика

Пост Лукацкого

22 September 2025 06:40

Если продолжить вчерашнюю заметку про трату времени на compliance, то можно сделать интересные выводы: 🤔
1️⃣ Каждый регулятор по отдельности считает, что делает важное дело (и в чем-то он прав). Но регуляторы почти никогда не смотрят по сторонам и не оценивают, что делают другие регуляторы. В итоге у нас рождаются требования уведомления об утечках ПДн в 4 разных регулятора, дублирующие требования ФСТЭК и Банка России, конфликтующие требования ФСТЭК и ФСБ и т.п. 🧐 Это даже если не упоминать, что в большинстве своем служащие регуляторов не работали в организациях, для которых они выпускают или проверяют нормативку, и не понимают всей их внутренней кухни.

2️⃣ Ряд регуляторов не понимает глубинных процессов, связанных с регулируемой ими деятельностью, что приводит к бессмысленной активности, которая только всех раздражает 😭, но которая никак не влияет на область регулирование. Например, тема персональных данных. Избыточные требования привели к тому, что в согласиях на обработку ПДн указываются сотни и тысячи наименований обработчиков ПДн и, конечно же, субъект не способен их всех просмотреть и оценить, что приводит к тому, что он просто жмакает "согласен" ☑️ на все или наоборот "не согласен" и тогда при следующем посещении он получает тоже самое всплывающее окно. И достаточно один раз клацнуть "согласен", как вся идея защиты ПДн рассыпается как карточный домик – ваши данные пошли по рукам и все последующие "несогласия" уже ничего не изменят. И это я даже не говорю про отношение современной молодежи к своим персданным как к чему-то прозрачному и не слишком ценному, что и так все знают, а значит защищать такие ПДн вообще никакого смысла нет, так как субъекту это просто не надо.

3️⃣ Специалисты по ИБ-compliance занимаются тем, что борются не с реальными угрозами ИБ, а с регуляторами ⚔️ Они делают все, чтобы регулятор не наказал их работодателей за невыполнение своих же дурацких требований. А регулятор выпускает новые требования, забыв отменить предыдущие, и начинается новая гонка. А потом на новый круг, и на новый... И так бесконечно ⌛

4️⃣ Единственную форму, которую принимают регуляторы, как доказательство выполнения каких-то норм - это отчетность, как правило, в бумажной форме. И вот мы уже вырубаем леса 🏞, чтобы регуляторы получили кипу бумаги и выбросили ее за ненадобностью. Вы думаете, они вдумчиво читают каждую страницу ваших уведомлений или доказательств выполнения вами их нормативных требований?

5️⃣ Никто из отечественных регуляторов не предусматривает поэтапную 🚶‍♂️ реализацию требований по защите, как это, например, сделано в HIPAA, где есть так называемая 21-дневная программа, которая подразумевает трату всего 10 минут в день для выполнения базовых шагов по повышению безопасности и соответствию требованиям. Да, это минимальный порог входа и потом все равно надо реализовывать больше всего, но по крайней мере вас не сразу тыкают носом в 200-400 страниц текста, которые надо реализовать "вчера" 🫵

6️⃣ Большинство ИБшников смирилось с такой ситуацией 🤷‍♀️ и не особо готово что-то менять. Не на уровне автоматизации, я об этом еще напишу, а на глубинном уровне. Ну есть и есть, "а что мы можем с этим поделать". Причем все все понимают, "нам же платят за то, чтобы не было штрафов от регуляторов". Это вообще странная история. Все понимают, что регуляторы в массе своей плодят шлак, который потом и проверяют в меру своего понимания 🤦‍♂️ Заказчики понимают, что это шлак и что он в массе своей не работает на практике, но не готовы с этим ничего делать, предпочитая выполнять все, что требуется регуляторами.

#регулирование

Пост Лукацкого

21 September 2025 14:14

По мировым и американским данным среднестатистический специалист по ИБ среднестатистической компании тратит от 7 до 10 часов в неделю 🕙 на задачи по соответствию требованиям, которые включают в себя мониторинг нормативных изменений, подготовку документации, аудиты, корректировки политик, взаимодействие с надзорными органами и другое (не беру в расчет ситуацию, когда в компании есть выделенное подразделение по ИБ-compliance). В России, с учетом цифровой зрелости этой функции я бы увеличил это значение до 10-15 часов в неделю ⌛ В моменты выпуска новых требований это значение вырастает, но если усреднить, то можно принять эти значения как факт.

Теперь давайте посчитаем. Если предположить, что выпускник ВУЗа выходит на работу в 23 года и работает до 65 (женщины до 60) и все это время он работает в ИБ в среднестатистической компании, то он потратит на бумажную ИБ от 20160 до 30240 часов, то есть от 840 до 1260 календарных суток (даже не рабочих дней). 3,5 года своей жизни, а это почти 5% от средней продолжительности в 77 лет ⌛️ (или от четверти до трети своего рабочего времени), будет потрачено на то, что не сильно приводит к результату в ИБ, так как хакеры, почему-то, не читают нормативку и ломают даже тех, кто соответствует стандартам и имеет сертификат или аттестат соответствия 🕙

Вы действительно думаете, что оно того стоит? Что именно ради этого вы учились 4, 5, 6 лет и желали наносить людям пользу? 🤔

#регулирование #рефлексия #математика #время

Пост Лукацкого

20 September 2025 19:26

Просто хочу поделиться – аукцион Meet For Charity, о котором я писал летом, завершился. Это не просто "покупка встречи" с кем-то. Это когда ты инвестируешь и знаешь, что твои деньги пойдут к тем, кто действительно в этом нуждается. В этот раз – в фонд "Провидение". Победителем стал Асан Ниязов – председатель правления МТИ-Банка. Человек серьезный, деловой, но при этом открытый для помощи людям.

Мы встретились в Кибердоме – месте силы российского кибербеза с крутой фиджитал-атмосферой, сочетающей уют реального мира и технологии цифрового (я даже на космолифте прокатился). Но главное – не стены, а смыслы. Смысл места, в котором мы встретились, и смысл нашего разговора, который получился живой, по делу. Обсуждали, как в финансах строить ИБ без паники, как соответствовать регуляторике, не превращаясь в бюрократическую машину, где все тормозит. Было полезно - и мне, и, надеюсь, Асану тоже.

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

Спасибо, Асан. Спасибо, Meet For Charity. Спасибо, Кибердом. За возможность делать добро не в теории, а на практике 🫰

Пост Лукацкого

20 September 2025 14:12

Немного истории вам в ленту (спасибо подписчику за ссылку). Первое компьютерное преступление в Советском Союзе, повлекшее за собой недопустимое – простой конвейера автозавода на трое суток 😂 Миллионные убытки; в те времена, когда доллар стоит 61 копейку. Но, похоже, тогда, как и сейчас, судьи не до конца понимали опасность киберпреступлений, давая, преимущественно, условные сроки 👩🏼‍⚖️

#история #ответственность #недопустимое

Пост Лукацкого

19 September 2025 19:57

Спросил как-то умудренный ИБшник начинающих специалистов по ИБ, выступая перед ними с лекцией:
– Почему во время недавнего инцидента с компанией А была взломана база данных?

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

– Никто из вас не ответил правильно, друзья мои, – произнес мудрый ИБшник. – Потому что систему изначально никто не проектировал с учетом требований безопасности и она открыто торчала в Интернет.

ЗЫ. Все совпадения случайны. Буква 🔤 - просто первая буква алфавита 🤔

#притча

Пост Лукацкого

19 September 2025 11:34

Неожиданное прилетело из-за океана. IDC выпустил ежегодный, по итогам 2024 года, отчет 📊 по рынку средств управления уязвимостями ("Worldwide Device Vulnerability and Exposure Management Market Shares, 2024"). И, что интересно, в 6-ку ключевых игроков (там их всего поименовано 6, а 7-й - это пресловутый other) включена и российская Positive Technologies, где я имею честь трудиться. И тут интересен не только факт включения российской компании (IDC все-таки старается соблюдать независимость и оценивать именно весь рынок, а не только то, что устраивает американцев), а то, что во-первых, IDC не побоялись включить в отчет компанию, на которую те же самые США наложили санкции. А во-вторых, что было бы, если этих санкций не было и какое бы тогда место занимала 🟥 в этом рейтинге? Допускаю, что CrowdStrike и ServiceNow мы бы точно обошли.

Наконец, и это не менее важно ☝️ В условиях непростой геополитики российским ИБ-игрокам, которые не побоялись выйти за пределы не только МКАДа, но и Российской Федерации, удается показывать очень неплохие результаты в части мировой экспансии. Это значит, что у ИБ-компаний, если им хотя бы не мешать, а может даже и помогать 🆘, есть прекрасные шансы реально показать свою экспортопригодность, а не только кричать на каждом углу об импортозамещении. Как раз быть лидером импортозамещения не сложно. Когда выгнали всех иностранцев, странно не показывать результаты; рынок большой – на всех хватит. А вот показать отличные цифры зарубежом, в жесткой конкурентной среде, это прям хороший знак. Значит есть шансы и по другим нишам, и для других компаний ↗️

#оценказащищенности #рынок #статистика

Пост Лукацкого

26 September 2025 06:40

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 и факс.

Если оператор использует сторонних поставщиков (например, услуги по эксплуатации, безопасности, обслуживанию), то оператор обязан предусмотреть в контрактах с ними обязанность своевременного сообщения о инцидентах и координации в расследовании. Эта мера направлена на то, чтобы цепочка реагирования была непрерывной, и оператор мог выполнить свои обязательства даже если часть инфраструктуры обслуживают третьи лица.

Если оператор задерживает, скрывает или лжет в уведомлении об инциденте – на него могут быть наложены штрафы; и ответственность могут нести не только юридическое лицо, но и конкретные ответственные лица. Однако если оператор смог доказать, что он применил "разумные и необходимые меры ИБ", своевременно уведомил органы и уменьшил вред – он может быть освобожден от ответственности или получить более мягкую санкцию 🐲

#регулирование #управлениеинцидентами

Пост Лукацкого

25 September 2025 15:32

Депутаты продолжают настаивать на том, что если у россиянина больше 6️⃣1️⃣ банковских карт, то он мошенник и дроппер и надо с такими бороться 😡 Банк России поддерживает эту инициативу.

Интересно, регулятор же изменит свои рекомендации, в которых прямо писал про то, что клиентам банкам стоит заводить виртуальные карты 💳 в целях безопасности, снижающие риски потерь денег? А виртуальных карт только в одном банке может быть с десяток – для каждого сервиса или маркетплейса своя. Тогда, во-первых, для разных сервисов можно свои лимиты устанавливать, а во-вторых, сразу станет понятно, откуда утекли данные, если с карты вдруг начнут пропадать деньги 🤒

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

#регулирование #мошенничество

Пост Лукацкого

25 September 2025 06:40

В комментах попросили прокомментировать тему оффбординга (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

Пост Лукацкого

24 September 2025 15:41

Чем зрелее 📈 программа повышения осведомленности по ИБ, тем более персонализированной она будет. Идея простая (я про нее писал выше). Для разных ролей хакеры используют обычно разные способы атак, а значит требуются и разные методы проверки знаний и навыков, тестирующие разные привычки и защитные меры, присущие каждой роли. Учим не всех всему одинаково, а каждого важному именно для него! 🧑‍💻

Как персонализировать обучение: 🤔
💡 Контент. Примеры из типичных процессов тестируемых (счета/договора для финансовых работников; 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

Пост Лукацкого

24 September 2025 06:40

Если вы, прочитав вчерашнюю заметку, решили: "Ну давай уже, рассказывай про пятый уровень, я сразу на него нацелюсь", то разочарую, – перепрыгнуть с первого или даже второго уровня сразу на 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

Пост Лукацкого

23 September 2025 17:01

И кто теперь скажет, что я не пророк? Так что если вы думаете иногда: «Какую же чушь он написал», то знайте, это не чушь, это предвидение 🔮

#тенденции #санкции

Пост Лукацкого

23 September 2025 11:34

Ну и чтобы не быть голословным 😱 Пример, что можно сделать на 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

Пост Лукацкого

22 September 2025 19:43

Интересное 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 🤔

#фишинг

Пост Лукацкого

22 September 2025 11:34

Мои ближайшие мероприятия (из публичных):
➡️ 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ам, стартующий уже через пару недель, но про него я уже писал.

#мероприятие #обучение

Пост Лукацкого

21 September 2025 19:44

Что объединяет пятничные взломы аэропортов 🛫 Брюсселя, Хитроу в Лондоне, Бранденбург в Берлине? То, что их никто не ломал. Взломан был поставщик системы регистрации на рейс, которая использовалась в упомянутых аэропортах, и предоставлялась компанией Collins Aerospace (ею владеет RTX/Ratheon). Классическая атака на подрядчика, через которую пострадали и связанные с ней компании 🛩

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

#sypplychain

Пост Лукацкого

21 September 2025 08:40

Скоро сказка сказывается, да долго дело делается... В марте писал про свою статью про выбор накопителей 💾 и архитектур хранения событий безопасности для SIEM и SOCов. И вроде материал был написан, но все руки не доходили его вылизать и выложить. Но вроде все доделал – отправил на финальную корректуру и скоро, надеюсь, поделюсь ссылкой на сей лонгрид ✍️

#soc #статья

Пост Лукацкого

20 September 2025 14:12

Исторические заметки

Рассказывает Вера Алексеевна Архангельская (c 1976 года- помощник прокурора Автозаводского района г.Тольятти прокуратуры Куйбышевской области, с 1982 года- старший помощник прокурора там же, с сентября 1992 года- судья Автозаводского районного суда г.Тольятти, c июня 2014 года пребывает в отставке):

"В 1983 году в СССР было совершенно первое в истории преступление в сфере высоких технологий – хакнули ПО на АВТОВАЗе, в результате чего конвейер встал на три дня. Возник прецедент: совершено преступление, за которое не предусмотрено наказание.

Первым хакером в истории СССР оказался простой программист Мурат Уртембаев, которому прочили блестящую карьеру математика в МГУ, но он отказался от научной стези, и по целевому распределению попал на АВТОВАЗ. Там его таланты никто не оценил, и он решил доказать, что чего-то да стоит.

В Управлении автоматической системой для подачи механических узлов на конвейер, в котором работал Мурат, схема работы была следующей – программист, если считал нужным, вносил изменения в ПО, но не оставлял никаких данных или отметок о внесенных изменениях.
Уртембаев создал патч к основной программе-счетчику, которая отмеряла циклы подачи узлов на линию конвейера. Патч Мурата сбивал ритм счетчика. На конвейере, где заданная деталь должна быть поставлена в четко ограниченное время, сбой в автоматике даже на секунду будет фатальным для производственной линии, где все выверено и просчитано до мелочей.

Мурат подстраховался, создав себе алиби, – запуск адского патча Уртембаев запрограммировал на день своего выхода из отпуска.

Расчет был такой: я возвращаюсь из родных степей Казахстана, обнаруживаю сбой и совершаю настоящий производственный подвиг, спасая конвейер от неминуемой катастрофы. Почетные грамоты, слава, хвала и поездка в Туапсе прилагаются.

Но вмешалось одно непредвиденное обстоятельство – программа запустилась на два дня раньше.
Никто ничего не понимал. Автоматика точно сошла с ума. Инженеры хватались за сердца – шоковая производственная терапия в течение трех дней на конвейере не прошла для них бесследно.

Бороться с ЧП были брошены лучшие специалисты. Они проверили оборудование, отдельные узлы, саму ЭВМ, но технически все было в порядке. Следов физического вмешательства не было найдено.

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

Благодаря проделке Мурата, завод понес многомиллионные убытки.

Мурат Уртембаев пришел на явку с повинной.
Статьи, которая в нынешнем УК квалифицируется в ст. 273 деяние Уртембаева, как «создание, использование и распространение вредоносных программ для ЭВМ» и предусматривает лишение свободы на срок от трех до семи лет, тогда еще не было.

Первого хакера в нашей истории осудили за умышленные хулиганские действия и дали полтора года условно с возмещением ущерба, который был оценен в стоимость двух «Жигулей». Мурат вынужден был отрабатывать наказание слесарем на конвейере.

Рассматривал уголовное дело председатель Автозаводского суда Бойко А.С., адвокат Московский В.П., прокурор Архангельская В.А. Дня через три в газете "Известия" была опубликована статья «Умысел», которую опубликовали СМИ за рубежом. Точно не помню какие страны, но Италия и Франция точно. У Администрации ВАЗа были неприятности".

Пост Лукацкого

20 September 2025 08:40

Помните историю про хакера и солонку? 🧂 Этакая сатира о том, как сообщение об уязвимости превращается в цепь панических, неадекватных и контрпродуктивных мер: от жалобы хакера до массовых ограничений, паранойи, судебных разбирательств и бессмысленных технических исправлений, которые в итоге ухудшают жизнь людей и не решают реальной проблемы 🤦‍♂️ Вчера в комментах эта история всплыла и я подумал, а как бы я поступил в этой ситуации, чтобы с одной стороны отреагировать на сообщение об уязвимости, а с другой – не парализовать работу столовой и не снизить лояльность посетителей?

1️⃣ Моделирование угроз 🔓
➖ Действительно ли плохой парень способен массово отравить всех, или речь идет о единичных случаях? Да, единичные случаи тоже неприятны, но и масштаб тоже надо учитывать.
➖ Стоит ли ущерб тех неудобств, которые создают "одноразовые пароли на солонках"?
➖ Выбор адекватных защитных мер.

2️⃣ Защитные меры 🛡
➖ Контроль целостности – официанты в начале смены проверяют солонки (простая инспекция, без паспортов и кодов).
➖ Ограничение доступа – солонки пополняются только из проверенных источников (например, опломбированные пакеты соли, хранящиеся на закрытом складе).
➖ Разделение ответственности – персонал кухни отвечает за наполнение солонок, зал – за их расстановку и проверку.
➖ Незаметная защита, например, пломбы или маркировка, которая сразу покажет вскрытие.
➖ Объяснительные таблички (без излишней паранойи): "Солонки опломбированы для вашей безопасности" и "Taste something, say something" и т.п. Посетители чувствуют заботу и не сталкиваются с бюрократией, но знают, что могут обратиться к любому официанту, если что-то пошло не так.

4️⃣ Мониторинг и реагирование 🔍
➖ Если кто-то заметил странности (например, вкус соли изменился), то есть процедура сообщения персоналу.
➖ Выборочные проверки – не каждую солонку каждый день в лабораторию на анализ, а по расписанию и выборочно. Иногда обычные тестовые полоски для ускорения.
➖ Работа с ложными срабатываниями – чтобы не плодить хаос, отсеивать неподтвержденные жалобы.

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

#бизнес

Пост Лукацкого

19 September 2025 15:40

ИТ-холдинг Т1 провел интересное исследование 🔬 32 областей российской экономики, в которых активно появляются и развиваются стартапы. Компания проанализировала 4000 "молодых да ранних" и составила DGCompass, документ на 200+ страниц, в котором описаны все рассмотренные ниши и даны интересные цифры по ним. Одной из 32-х отраслей оказался и кибербез, попавший на поляну единорогов 🦄

Стартапом в исследовании считаются те компании, которые показывают выручку до 2,5 миллиардов рублей, насчитывает не более 150 работников, не старше 5 лет и стоимость самой компании не превышает 25 миллиардов рублей 🤑 Под эти критерии попало 78 компаний, работающих в разных нишах и помогающих решать разные задачи. Не буду пересказывать все – просто посмотрите выдержку из DGCompass, касающуюся именно ИБ-сферы 📖

Будь я заказчиком или инвестором, я бы хотел еще видеть имена всех этих стартапов, чтобы либо рассмотреть их для своей инфраструктуры, либо для инвестиций 🤓 Но даже без этого работа проведена хорошая – становится понятно, какие направления привлекают внимание стартаперов, а какие нет, где они рентабельные, какая выручка может ожидать начинающих предпринимателей и т.п. Прям есть над чем задуматься... 🤔

И, кстати, по моим сведениям, сейчас начинается прям активная охота за ИБ-стартапами. Одна компания, с коллегами из которой я общался, планирует до конца года закрыть пять сделок, другая - еще столько же. Третья ограничится 2-3 поглощениями 😋

#рынок #стартап

ЗЫ. Потихоньку ставлю теги на все посты в канале, чтобы было проще ориентироваться. Сейчас вот тег #стартап во всех постах проставил. Так, глядишь и все посты в итоге помечу, а не только те, что с ноября 2024 года.

Пост Лукацкого

19 September 2025 06:40

Коллеги написали про новые требования к новому классу средств защиты, предложенному ФСТЭК, - СОР, то есть к средствам обнаружения и реагирования, которые в простнародье называются EDR. И вот неоднозначное у меня отношение к этим требованиям. Не к их содержанию, а к появлению еще одних требований по защите оконечных устройств. Ведь у нас уже есть руководящие документы по:
➡️ средствам защиты от несанкционированного доступа
➡️ средствам антивирусной защиты
➡️ межсетевым экранам уровня узла (класса В).

Теперь появляется еще один тип средств защиты, который включает в себя и что-то от СЗИ от НСД, и что-то от антивируса, и что-то от хостового МСЭ.

И получается, что сейчас действительно складывается ситуация, когда одно и то же оконечное устройство должно одновременно соответствовать нескольким наборам требований (СЗИ от НСД, антивирус, хостовой МЭ, теперь СОР/EDR). И это приводит к пересечениям, дублированию и иногда даже противоречиям; не говоря уже об увеличении затрат на сертификацию.

Я вижу три возможных пути решения этой проблемы:
1️⃣ Сохранить отдельные документы, но переработать их. Каждое средство защиты продолжает жить в своей «нише» (антивирус, СЗИ от НСД, МСЭ, СОР). Но требования должны быть жёстко разведены, без пересечений. Например:
➖Антивирус → только обнаружение и лечение вредоносного ПО.
➖СЗИ от НСД → контроль доступа и предотвращение обхода ОС.
➖Хостовой МЭ → сетевые фильтры уровня узла.
➖СОР → поведенческая аналитика, расследование, реагирование.
➖Преимущество: сохраняется преемственность.
➖Недостаток: получится громоздко и по-прежнему много возможных слепых зон. Да и скорость переработки принятых РД не внушает оптимизма.

2️⃣ Создать единый документ для всех средств защиты оконечных устройств, где прописывается базовый набор требований для всех средств защиты узлов/хостов. Внутри документа можно ввести подразделы или профили, описывающие разные направления (доступ, антивирус, сеть, обнаружение и реагирование, в перспективе, NAC, управление уязвимостями и т.п.). Такой подход ближе к международным практикам (NIST SP 800-53, CIS Controls), где требования задаются системно.
➖Преимущество: единый источник, меньше противоречий.
➖Недостаток: документ будет все равно большим и сложным в поддержке.

3️⃣ Единый документ с классами средств защиты узлов. Вместо отдельных типов СЗИ ввести «классы средств защиты оконечных устройств», как это сделано для межсетевых экранов. Например:
➖Класс 1 — базовая защита (антивирус + простейший контроль доступа).
➖Класс 2 — расширенная защита (добавляется хостовой МЭ, поведенческий анализ).
➖Класс 3 — полный стек (EDR/СОР с расследованием и реагированием).
➖Тогда разработчики смогут выпускать либо «лёгковесные» продукты, либо комплексные решения.
➖Преимущество: гибкость, стимулирование развития универсальных агентов (EDR, XDR).
➖Недостаток: придётся отказаться от привычной парадигмы отдельных СЗИ.

Что лучше из описанных вариантов? Если смотреть стратегически - вариант №3 (классы средств защиты) выглядит самым правильным.
➖ Он соответствует мировой тенденции интеграции функций (EDR часто включает и антивирус, и HIPS, и firewall). В идеале туда еще бы и VPN-клиента засунуть, и NAC-агента, и Identity, но это уже утопия.
➖ Упрощает сертификацию: проверяешь один продукт по классу, а не три разных по отдельным документам.
➖ Позволяет организациям выбирать уровень защиты в зависимости от выбранной модели угроз.

Но для плавного перехода, возможно, стоит пойти через вариант №2: объединить всё в единый документ, сохранив профили/подразделы. А потом уже эволюционно перейти к системе классов.

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