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

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

Уникальный контент про кибербезопасность от Алексея Лукацкого (@alukatsk) - мысли, полезные ссылки, комментарии к текущим событиям, юмор и мемасики. Канал личный - мой работодатель никак не влияет на то, что здесь публикуется. Рекламу не размещаю!!!

Юзернейм
@alukatsky
Категория
Технологии
Страна
РоссияРоссия
Создан
, 9 лет
Подписчики38 393+2 за 2 дня
Просмотров на пост, 7 дн.5 096за 7 дней
ERR13,27 %за 7 дней

Подписчики, 30 дней

1 нояб. – 3 нояб.+2 (0%)

Показать таблицей
ДатаПодписчики
1 нояб. 2026 г.38 391
2 нояб. 2026 г.38 390
3 нояб. 2026 г.38 393

Средние просмотры поста по дням

По дню публикации

Показать таблицей
ДатаПросмотров на пост
29 окт. 2026 г.5 376
30 окт. 2026 г.5 803
31 окт. 2026 г.5 880
1 нояб. 2026 г.6 177
2 нояб. 2026 г.5 250
3 нояб. 2026 г.3 673
4 нояб. 2026 г.2 333

Самые просматриваемые за месяц

  1. 01

    Блумберг пишет про кибератаки, имеющие физические последствия. Вопрос атрибуции оставлю в стороне, а сами примеры достаточно интересные: 6️⃣ В крематории в испанской провинции Аликанте неожиданно перестали работать кремационные печи. 2️⃣ В Каталонии, на заводе, производящем трансформаторы для возобновляемой энергетики, произошел сбой оборудования, который привел к пожару. 3️⃣ На производственных и складских объектах двух испанских виноделен нарушилась работа систем отопления, вентиляции и кондиционирования. Температура начала неконтролируемо повышаться, что создало угрозу технологическим процессам и продукции. 4️⃣ В декабре 2024 года жители датского Тюребю (Tureby) остались без воды. Настройки давления в системе управления были обнулены. После восстановления подачи воды давление резко выросло, что привело к повреждению подземных труб. Позднее выяснилось, что пароль системы управления был 1234. 5️⃣ В 2024 году на мясоперерабатывающем предприятии около Лос-Анджелеса хакеры остановили холодильное оборудование. В результате испортилось около 900 кг мяса, произошла утечка аммиака и потребовалась эвакуация работников. #инцидент #ущерб #кии

    Превью ссылки
    Просмотры6,55 тыс.
    Пересылки44
    Реакции30
    Комментарии19
  2. 02
    Просмотры6,15 тыс.
    Пересылки95
    Реакции51
    Комментарии23
  3. 03
    Просмотры6,08 тыс.
    Пересылки47
    Реакции12
    Комментарии9
  4. 04
    Просмотры5,99 тыс.
    Пересылки20
    Реакции65
    Комментарии15
  5. 05

    Без текста

    Фотоальбом
    Просмотры5,93 тыс.
    Пересылки46
    Реакции—
    Комментарии—

Новые посты

#15549Фото
Просмотры2 001−61%к среднему
Пересылки18
Реакции14
Комментарии7
#15548Превью ссылки

Помню, в Cisco SAFE, еще первой версии, были зафиксированы аксиомы, из которых выводились принципы защиты. Одной из таких аксиом была "любое устройство с IP-адресом может стать целью хакеров". Смотря сейчас на кейсы последних дней, вспоминаю этот принцип, сформулированный более 20 лет назад и до сих пор остающийся актуальным. Двухнедельной давности история с холодильниками продолжается. Помимо Франции схожие кейсы повторились в Бельгии, Голландии, Люксембурге, Дании, Германии, Италии, Ирландии, Португалии, Польше, Швеции, Румынии, Финлянди и Эстонии. Сценарий везде один и тот же – удаленное изменение температуры с последующей порчей продуктов, которые приходится выбрасывать. Многие валят все на Danfoss и уязвимости в ее программном обеспечении. Датский же вендор встал в позу и утверждает, что, во-первых, он сразу посоветовал всем своим клиентам отключить удаленное управление, а во-вторых, уязвимый софт давно уже не поддерживается и его давно было пора поменять на новый. Связаны ли эти атаки с взломами холодильников в американском Пентагоне непонятно, но это не так уж и важно, если вспомнить аксиому. А в вашей модели угроз учтены атаки на холодильник? Вы в курсе, есть ли в вашем холодильнике модуль удаленного управления (независимо от того, включен он или нет)? Но идем дальше. Взлом системы оповещения. Снова, не так уж и важно, взломали через незащищенный API или еще как-то. Это цель, так как она не только имела IP-адрес, но и была доступна из Интернет. А так как это далеко не первый случай взлома систем оповещения, то в целом было логично (да, задним числом, я тоже умный) предусмотреть, что кто-то попробует потыкать в эту систему. Причем взлом был не один и не два; вот небольшой список: 📣 Февраль 2013 – США – Взлом оборудования экстренного оповещения нескольких телеканалов; в эфир вышло ложное предупреждение о "зомби". FCC указала на заводские пароли и недостаточную защиту оборудования. 📣 Январь 2018 – Гавайи – Предупреждение о приближении баллистической ракеты отправили по ошибке; опровержение последовало примерно через 38 минут. 📣 Январь 2020 – Канада – Во время учений по ошибке выпустили предупреждение об инциденте на АЭС Pickering. Расследование обнаружило системные причины как самой отправки, так и задержки ее отмены. 📣 Март 2022 – Россия – Взломали сайт МЧС России, на котором разместили сообщения, связанные с войной в Украине. 📣 Март 2022 – Украина – После взлома эфира и бегущей строки телеканала "Украина 24" показали ложное сообщение о капитуляции Владимира Зеленского; отдельно распространялось поддельное видео. 📣 Февраль 2023 – Россия – На ряде радиостанций прозвучали ложные сигналы воздушной тревоги, что связали с атакой на инфраструктуру спутникового оператора. Позднее МЧС сообщило о взломе серверов радио- и телеканалов, через которые передавали ложные предупреждения. 📣 Июнь 2026 – Бразилия – После несанкционированного доступа через государственную платформу Defesa Civil Alerta разослали ложные предупреждения на телефоны в нескольких регионах. 📣 Ноябрь 2026 – Украина и Россия – В Украине после взлома приложения "Повітряна тривога" появились ложные уведомления об опасности. В России МЧС подтвердило атаку на свое приложение и рассылку ложных сообщений о ядерной угрозе, заявив, что сирены, СМС, теле- и радиоканалы не затронуты. Так что помните, что любое устройств, узел, сервис, виртуалка и вообще все, что имеет IP-адрес, может быть мишенью. Да-да, с автомобилями та же фигня. Из этого и стоит исходить при моделировании угроз. Да, такой узел может быть признан некритичным, но это уже потом. Отбрасывание его с самого начала может сыграть злую шутку потом 🤔 ЗЫ. И в любом случае стоит помнить о том, что система оповещения – это в первую очередь про доверие, а не про технологии. #архитектура #модельугроз

Открыть в Telegram
Просмотры2 665−48%к среднему
Пересылки9
Реакции11
Комментарии0
#15547Фотоальбом
Просмотры2 346−54%к среднему
Пересылки10
Реакции—
Комментарии—
Динамика просмотровСкрыть динамику

Рост просмотров

Часов после публикации

Показать таблицей
Часов после публикацииПросмотры
0 ч213
10 ч2 346
  1. Всего сейчас2 346
#15546Фотоальбом
Просмотры2 320−54%к среднему
Пересылки9
Реакции—
Комментарии—
Динамика просмотровСкрыть динамику

Рост просмотров

Часов после публикации

Показать таблицей
Часов после публикацииПросмотры
0 ч197
10 ч2 320
  1. Всего сейчас2 320
#15545Фотоальбом
Просмотры2 373−53%к среднему
Пересылки9
Реакции18
Комментарии7
Динамика просмотровСкрыть динамику

Рост просмотров

Часов после публикации

Показать таблицей
Часов после публикацииПросмотры
0 ч203
10 ч2 373
  1. Всего сейчас2 373
#15544Фото
Просмотры4 239−17%к среднему
Пересылки21
Реакции36
Комментарии17
Динамика просмотровСкрыть динамику

Рост просмотров

Часов после публикации

Показать таблицей
Часов после публикацииПросмотры
0 ч0
5 ч3 465
15 ч4 239
  1. Через 6 часов3 465
  2. Всего сейчас4 239
#15543Фото
Просмотры5 371+5%к среднему
Пересылки14
Реакции60
Комментарии16
Динамика просмотровСкрыть динамику

Рост просмотров

Часов после публикации

Показать таблицей
Часов после публикацииПросмотры
0 ч0
2 ч1 964
5 ч3 862
8 ч4 302
26 ч5 371
  1. Через 1 час1 964
  2. Через 6 часов3 862
  3. Через 24 часа5 371
  4. Всего сейчас5 371
#15542Фото

Ну что, впору вернуться к моей майской заметке про форс-мажор при кибератаке на провайдера. На этот раз речь пойдет о Beget, который вчера столкнулся с последствиями серьезной атаки и который спустя несколько постов в канале, невнятных комментариев техподдержки наконец-то написал, что "баста карапузики, форс-мажор, мы ни за что не отвечаем". Буквально было написано другое, но суть та же. И судя по тому, что на сайте хостера до сих пор нет даже заглушки о ведущихся технических работах, мои серваки также недоступны и никакого письма от них нет (а в случае PHP2Shell они прислали аж два сообщения), то там жопа-жопа. Но сейчас не об этом... Сейчас нет времени подробно расписывать всю процедурную часть (я все-таки в отпуске), но мои ИИ-агенты, которые работали не на Beget'е, подсобрали несколько интересных дел, где пострадавшие от рук хакеров также пытались применить нормы 401 статьи ГК РФ об обстоятельствах непреодолимой силы. Итак: ⚖️Дело № А40-98900/2022 – Форс-мажор не доказан – Агент не смог надлежащим образом исполнить денежные обязательства перед принципалом. Он утверждал, что хакерская атака уничтожила часть электронной документации, заблокировала личные кабинеты и парализовала деятельность. Компания представила отчет независимых специалистов по реагированию на инцидент, сведения о возбуждении уголовного дела и доказательства уведомления контрагентов, но суд не признал этих обстоятельств достаточными для освобождения от ответственности. ⚖️ Дело № А40-129508/2022 – Форс-мажор не доказан – В споре с ООО "Л’Окситан Рус" ответчик ссылался на хакерскую атаку информационной базы, из-за которой, по его утверждению, он не мог определить размер долга. Суд указал, что не доказана причинно-следственная связь между атакой и невозможностью исполнить обязанность по оплате. ⚖️ Дело № А28-8461/2022 – Форс-мажор не доказан – Ответчик ссылался на DDoS-атаки, вызвавшие сбой в ЕГАИС со 2 по 5 мая 2022 года. При этом срок исполнения обязательства приходился на 11 мая. Суд не получил доказательств того, что сбой непосредственно вызвал последующую просрочку. ⚖️ Дело № А15-1085/2022 – Форс-мажор принят судом – В Республике Дагестан заказчик потребовал штраф за невозможность получить топливо по картам на ряде АЗС. Исполнитель объяснил проблему DDoS-атакой на информационный ресурс, обеспечивавший работу системы. Суд установил, что временная невозможность отпуска топлива была вызвана сбоем системы, а не действиями или бездействием поставщика, и отказал во взыскании соответствующего штрафа. ⚖️ Дело № А56-85885/2024 – В иске отказано – В результате сбоя у хостинг-провайдера Timeweb оказался недоступен сайт компании "Саната", занимавшейся бронированием санаториев. Заказчик потребовал возмещения реального ущерба и упущенной выгоды. Главная причина проигрыша истца оказалась не в том, что суд признал DDoS-атаку форс-мажором. Суд установил, что заказчик не доказал нарушение конкретных обязательств провайдера, причинную связь и размер убытков. Если найду время, то распишу алгоритм действий, как я его вижу, для клиентов, столкнувшихся с объявлением форс-мажора, и что клиент должны спрашивать в таких случаях, как доказательство именно обстоятельств непреодолимой силы 👨‍⚖️ #ответственность #инцидент

Открыть в Telegram
Просмотры5 387+6%к среднему
Пересылки71
Реакции54
Комментарии11
Динамика просмотровСкрыть динамику

Рост просмотров

Часов после публикации

Показать таблицей
Часов после публикацииПросмотры
0 ч0
5 ч2 951
9 ч4 122
30 ч5 387
  1. Через 6 часов2 951
  2. Через 24 часа5 387
  3. Всего сейчас5 387
#15541Фото
Просмотры5 221+2%к среднему
Пересылки43
Реакции6
Комментарии1
Динамика просмотровСкрыть динамику

Рост просмотров

Часов после публикации

Показать таблицей
Часов после публикацииПросмотры
0 ч0
7 ч2 106
21 ч4 813
34 ч5 221
  1. Через 6 часов2 106
  2. Через 24 часа4 813
  3. Всего сейчас5 221
#15540Превью ссылки

Смотрю на взломы последних дней, от облачных провайдеров до поставщиков ИИ-услуг и платформ, например, вот тут подборка свежая, и понимаю, что для измерения уровня защищенности подрядчиков мало ранжировать их по уровням критичности или выполнению ими требований вашей политики ИБ. Лучше использовать новую метрику – Maximum Delegated Exposure – максимальную величину последствий, которые могут возникнуть при полном захвате/компрометации подрядчика или одного доверенного компонента. При этом эта метрика должна иметь три независимых измерения, показывающих направления влияния инцидента на ваш бизнес: 💀 Data Exposure – максимальный объем доступной чувствительной информации, к которой имеет подрядчик или компонент. 💀 Action Exposure – максимальный масштаб критических действий, которые подрядчик или компонент способен выполнить в случае его "захвата" злоумышленниками. 💀 Financial Consumption Exposure – максимальные расходы, которые могут возникнуть при злоупотреблении выданными подрядчики или компоненту полномочиями. Можно даже отказаться от одной кумулятивной метрики Maximum Delegated Exposure и просто измерять три, каждую по отдельности 🤓 Ну и до кучи можно еще ввести Cost of Trust Withdrawal, стоимость немедленного отзыва доверия к поставщику, сервису, агенту или техническому компоненту, которые были скомпрометированы в результате атаки. И вот это уже кумулятивная метрика, которая включает не стоимость самой атаки, а скорее последствия решения, которое должно быть принято бизнесом: 💀 Какую функцию придется остановить? 💀 Какие юридические обязательства станут неисполнимыми? 💀 Какие альтернативные операции можно сохранить? 💀 Какие финансовые обязательства возникнут при остановке? 💀 Сколько времени потребуется, чтобы заново установить доверие и восстановить нормальную пропускную способность? #supplychain #метрики

Открыть в Telegram
Просмотры5 194+2%к среднему
Пересылки39
Реакции24
Комментарии13
Динамика просмотровСкрыть динамику

Рост просмотров

Часов после публикации

Показать таблицей
Часов после публикацииПросмотры
0 ч0
1 ч1 809
11 ч3 638
25 ч5 194
  1. Через 1 час1 809
  2. Через 24 часа5 194
  3. Всего сейчас5 194

Все посты

Связи