4️⃣— Когда код убивает

Джун сидел в полном оцепенении. Ошибка одного человека, одна неправильная команда — и интернет лег.

«А если баг не просто ломает прод, а ставит под угрозу жизни?» — крутил мысль джун.

— Сеньор, а были случаи, когда уязвимости в коде реально угрожали людям?

Сеньор поставил кружку с кофе:
— Ты готов? Это уже не просто баги, это реальные катастрофы.

DevSecOps нахмурился, сеньор продолжил:
— Jeep Hack, 2015. Два исследователя смогли взломать Jeep Cherokee, подключившись к его развлекательной системе. Через неё они получили доступ к тормозам, рулю и двигателю. Отключили тормоза во время движения. В реальном мире.

Джун сглотнул:
— Но… развлекательная система не должна влиять на управление машиной!

Секьюрити ресёрчер покачал головой:
— А код писал кто-то, кто думал иначе. Изоляции не было, контроль отсутствовал. И в итоге мультимедийная система смогла дать команду на тормоза.

Безопасник добавил:
— А ещё был Tesla Bluetooth Exploit в 2020-м. Через уязвимость в Bluetooth злоумышленники смогли разблокировать машину и угнать её.

— То есть, машина вообще не проверяла, кто с ней связывается?

— Она верила, что, если пришёл сигнал, значит, он законный.

DevOps нервно хмыкнул:
— Это как если бы твоя дверь автоматически открывалась перед каждым, кто скажет: «Я — это ты».

— И это реально случилось?

Секьюрити ресёрчер кивнул:
— Это случается постоянно. Разработчики забывают, что код работает в реальном мире, а не в тестовом окружении. И вот так машины угоняют удалённо, самолёты падают из-за ошибок автопилота, а больницы остаются без электричества из-за кибератак.

Джун почувствовал, как по спине пробежал холодок.

Продолжение следует...

Вынос пользы для джуна:

▪️Код = реальная угроза. Ошибка в системе может стоить чьей-то жизни.

▪️Изоляция критична. Развлекательная система не должна управлять тормозами, так же как UI не должен иметь доступ к базе данных напрямую.

▪️Контроль взаимодействий обязателен. Любая внешняя команда должна проверяться, а не выполняться безусловно.

▪️Допускай, что систему атакуют. Проектируй так, будто злоумышленник уже внутри сети.

Пояснительная бригада:

Tesla Bluetooth Exploit (2020): злоумышленники использовали уязвимость в Bluetooth, потому что не было строгой проверки подлинности сигнала. Подробности читай тут.

Jeep Hack (2015): отсутствовала изоляция между мультимедиа и критичными системами. Подробности читай тут.

Default Deny: система должна по умолчанию блокировать доступы, а не предоставлять их всем желающим.

Critical System Segmentation: все критические модули должны быть физически и логически отделены от некритичных.

Ставь 👍, если и у вас было, что критичная система стала доступна «по глупости».
Со всеми бывает.

#поиграемвКИ

Без проверки — без защиты.
#поиграемвКИ

Когда-то ты попал на наш канал, значит, тебе не всё равно, какой мир мы с тобой кодим. Ты знаешь, что код — это власть.
Вопрос в том, насколько он устойчив к хаосу?

Узнай на бесплатном мини-курсе «Кибериммунитет за 3 вечера», который стартует 1️⃣2️⃣. 0️⃣5️⃣.
👉 https://vk.cc/cKFXqU

5️⃣ — Никому нельзя верить

Джуну было не по себе: «Получается, если нет изоляции — можно угнать машину? Если нет контроля — можно взломать целую сеть? А если…»

— А если взломают не нас, а кого-то, кому мы доверяем?

Секьюрити ресёрчер пристально посмотрел на него:
— Ты только что понял главный принцип информационной безопасности. Никому нельзя верить. Агент Малдер, только в IT.

— Но… Мы же работаем с проверенными сервисами! Мы обновляемся только с официальных репозиториев!

Безопасник с ухмылкой взял листок и написал:

SolarWinds Hack, 2020.

DevSecOps кивнул:
— В 2020 году хакеры взломали компанию SolarWinds — поставщика ПО для мониторинга. Они подменили обновление и разослали его клиентам.

Джун напрягся:
— И кто пострадал?

Сеньор откинулся в кресле:
— Все. Microsoft, Cisco, Intel, даже Минфин США. Они скачали обновление, доверившись вендору. А вендор уже был скомпрометирован.

Джун ошеломлённо выдохнул:
— Но как… Как защититься, если даже обновления могут быть заражены?

Секьюрити ресёрчер поднял палец:
— Zero Trust. Никому нельзя верить. Даже своим серверам, даже своему коду. Всё должно проверяться на каждом этапе.

DevOps хмыкнул:
— То есть, ты предлагаешь относиться к каждому пакету обновления, как к потенциальной бомбе?

— Да. И проверять, что эта бомба обезврежена, прежде чем её запускать.

Джун посмотрел на терминал. Там мигало приглашение на установку нового апдейта.

Он задумался.

Продолжение следует...

Вынос пользы для джуна:

▪️Zero Trust = не доверяй никому. Любая система может быть скомпрометирована.

▪️Обновления = возможная угроза. Перед установкой проверяй их источник и целостность.

▪️Минимизируй доверие к сторонним сервисам. Даже официальные репозитории могут быть взломаны.

▪️Логи и мониторинг — твои друзья. Если где-то что-то пошло не так, система должна это зафиксировать.

Пояснительная бригада:

SolarWinds Hack (2020): атака через цепочку поставок. Взломав поставщика ПО, злоумышленники распространили заражённые обновления по всему миру. Подробности читай тут.

Zero Trust Security Model: концепция, в которой любой запрос на доступ требует проверки, даже если он исходит из внутренней сети.

Code Signing: проверка цифровых подписей обновлений, чтобы убедиться, что они не были подменены.

Behavior-based Detection: отслеживание аномального поведения в сети, чтобы выявлять взломы даже после их проникновения.

💬 Пиши в комменты: какой неожиданный сторонний сервис подвёл вас больше всего?

#поиграемвКИ

6️⃣— Взлом уже произошёл, просто ты об этом не знаешь

Джун закрыл окно обновлений и задумался.

«Если даже обновления могут быть заражены, если доверять нельзя никому… Значит, что? Взлом неизбежен?»

Он посмотрел на секьюрити ресёрчера, и тот, словно читая мысли, спокойно кивнул:
— Ты наконец-то пришёл к главному правилу. Assume Breach.

Джун нахмурился:
— То есть, мы должны жить с мыслью, что система уже взломана?

DevSecOps ухмыльнулся:
— А ты уверен, что сейчас в сети нет злоумышленника?

Джун вздрогнул:
— Но… Но ведь у нас файрволы, антивирусы, защитные политики!

— А у Equifax в 2017 году тоже всё это было.

Безопасник поднял взгляд от ноутбука:
— Equifax? Это которые потеряли данные 147 миллионов человек?

Сеньор кивнул:
— Да. Они использовали Apache Struts — фреймворк, который имел уязвимость. Её эксплуатировали хакеры, и компания даже не заметила утечку, пока не стало поздно.

— Но ведь можно было обновить Struts!

— Можно было. Но не сделали. Потому что думали, что у них «и так всё нормально».

Секьюрити ресёрчер покачал головой:
— Без Assume Breach ты живёшь в мире, где защита идеальна. А в реальном мире атака уже случилась — ты просто ещё не знаешь об этом.

Джун нервно посмотрел на свой терминал с апдейтом:
— Значит, система должна быть готова к взлому с самого начала?

— Именно. Минимизация, изоляция, контроль. Ты не сможешь предотвратить все атаки. Но ты можешь сделать так, чтобы даже успешный взлом не привёл к катастрофе.

Джун глубоко вдохнул. Дональд Кнут такого не писал, этому не учили в вузе: «Предположи, что взлом уже произошёл…».

Продолжение следует...

Вынос пользы для джуна:

▪️Assume Breach: не «если нас взломают», а «нас уже взломали, просто мы ещё не знаем».

▪️Обновления критичны. Уязвимость Apache Struts стоила Equifax утечки 147 миллионов записей.

▪️Мониторинг = жизнь. Если ты не следишь за сетью, злоумышленники могут прятаться там годами.

▪️Дизайн с учётом компрометации. Даже если атакующий проник внутрь, он не должен получить критичный доступ.

Пояснительная бригада:

Equifax Hack (2017): хакеры использовали уязвимость в Apache Struts, из-за чего утекли персональные данные 147 миллионов человек. Подробности читай тут.

Assume Breach: стратегия безопасности, предполагающая, что система уже скомпрометирована. Главная цель — обнаружить вторжение и ограничить ущерб.

Zero Trust + Assume Breach: ни один сервис не доверяет другому без строгой проверки, а любая аномалия рассматривается как потенциальный взлом.

EDR и SIEM: системы мониторинга поведения процессов и анализа логов помогают выявлять подозрительные активности.

Ставь 👍, если было такое, что ты узнал о взломе системы позже, чем был должен.

#поиграемвКИ

Ты узнаешь о взломе последним...
#поиграемвКИ

❌Не надо так!
✔️ А вот так надо 👉 Записаться на курс «КИБЕРИММУНИТЕТ ЗА ТРИ ДНЯ»

7️⃣— Меньше кода — меньше боли
Начало Игры в кибериммунитет 👈

Джун смотрел на свой код: «А если взлом уже произошёл, то что делать? Как уменьшить ущерб»? — не отпускала его мысль.

— Сеньор, а можно ли сделать так, чтобы атаковать систему было сложнее?

Сеньор усмехнулся:
— Можно. Пиши меньше кода.

— Эм… Чего?

DevSecOps кивнул:
— KISS и YAGNI. Чем меньше кода — тем меньше багов, меньше поверхностей атаки, меньше точек отказа.

— Но код всё равно нужен…

Секьюрити ресёрчер хмыкнул:
— Код — это не решение проблемы. Код — это новая проблема.

Джун нахмурился:
— Но ведь нам нужны функции, нужно расширять продукт! Бэклог как-никак...

DevOps вздохнул:
— Сначала нужен работающий прод, а не кладбище фич, которые никто не использует.

Безопасник откинулся в кресле:
— Capital One, 2019 год. Токен доступа к AWS S3 утёк. Хакеры воспользовались им, получили доступ к хранилищу и украли данные 100 миллионов клиентов.

Джун моргнул;
— И что, этого нельзя было предотвратить?

DevSecOps кивнул:
— Можно было. Если бы работал Default Deny, этот токен ничего бы не дал. Если бы был жёсткий контроль доступа (RBAC, IAM), атака была бы невозможна. Если бы использовали изоляцию через namespaces и контейнеры, взлом не распространился бы дальше.

Сеньор усмехнулся:
— Но самое простое — если бы этот токен вообще не существовал.

Джун задумался: «Чем меньше кода — тем меньше точек атаки. Чем меньше прав — тем сложнее взломать».

Что-то в этом было...

Продолжение следует...

Вынос пользы для джуна:

▪️Минимизация = безопасность. KISS и YAGNI — это не просто про стиль кода, а про реальную защиту.

▪️Изоляция критичных данных. Контейнеры, namespaces и fault domains — всё должно быть чётко разделено.

▪️Default Deny: по умолчанию всё запрещено, а не «разрешаем, а потом разбираемся».

▪️Контроль на каждом уровне. RBAC, IAM, IPC — управление правами важно не только в коде, но и в инфраструктуре.

Пояснительная бригада:

Capital One Hack (2019): хакеры получили утекший токен AWS S3, потому что не было строгой политики доступа и изоляции. Подробности читай тут.

KISS (Keep It Simple, Stupid) и YAGNI (You Aren’t Gonna Need It): чем проще система, тем меньше атакуемых поверхностей.

Изоляция: использование контейнеров (Docker, Kubernetes), namespaces, fault domains для минимизации воздействия атак.

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

RBAC (Role-Based Access Control), IAM (Identity and Access Management): управление правами доступа, чтобы злоумышленники не могли получить лишние привилегии.

💬 Пиши в комменты: какой кусок легаси-кода у вас никто не хочет трогать, но все знают, что он критичен?

#поиграемвКИ

8️⃣— Финал: будущее кода — за тобой!

Джун сидел перед монитором, размышляя: «Минимизация. Изоляция. Контроль. Assume Breach. Zero Trust. Чем глубже я копаю, тем больше понимаю, насколько уязвим код, если его не проектировать правильно».

Секьюрити ресёрчер подошёл и молча поставил перед ним чашку чая:
— Думать начал?

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

Секьюрити ресёрчер улыбнулся:
— Если твоя система готова к атакам. Если её нельзя сломать одной командой. Если она защищает даже самого неосторожного пользователя. Тогда ты на правильном пути.

— Но ведь никто так не пишет…

— Пока не пишет. Но кто-то должен начать.

— То есть… я?

— Не только ты. Всё новое начинается с тех, кто не боится менять старые правила.

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

— Именно.

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

Конец? Нет. Это только начало!

Вынос пользы для джуна:

▪️Код — это не просто работающий продукт. Он должен быть защищённым от атак с самого начала.

▪️Ты не можешь остановить атаки, но ты можешь сделать так, чтобы они не сломали систему.

▪️Zero Trust, Assume Breach, минимизация, изоляция — не просто слова, а реальный способ защитить данные.

▪️Будущее кибериммунного кода зависит от тебя. Пиши его правильно!

Пояснительная бригада:

Кибериммунитет — это не отсутствие уязвимостей. Это архитектура, в которой уязвимости не дают атакующему уничтожить систему.

Secure by Design: защита закладывается в архитектуру, а не настраивается поверх неё.

Principle of Least Privilege: чем меньше прав у кода, тем сложнее его взломать.

Continuous Monitoring: кибербезопасность — это не настройка раз и навсегда, а постоянный процесс анализа и адаптации.

💬 Пиши в комменты: что в кибериммунном подходе к разработке тебе кажется тебе самым сложным?

#поиграемвКИ

Будущее — за теми, кто пишет код правильно.

Научиcь кибеиммунному подходу. Спаси планету!
Регистрация на бесплатный курс
📝 https://vk.cc/cKFXAx

#поиграемвКИ

🤴🏻Что общего у кибериммунитета и смерти Кощея на конце иглы?

Сегодня мы расскажем о трех принципах кибериммунного подхода на примере Кощеевой смерти (внезапно, да? 🙃)

«…Нелегко с Кощеем сладить: смерть его на конце иглы, та игла в яйце, то яйцо в утке, та утка в зайце, тот заяц в сундуке, а сундук стоит на высоком дубу, и то дерево Кощей, как свой глаз, бережет», — вещает Баба Яга в сказке про Царевну-лягушку.

Итак, что же сделал Кощей?
Во-первых, минимизировал поверхность атаки до острия иглы. Во-вторых, изолировал компоненты друг от друга или, вернее, друг в друге. В-третьих — предположительно — следил за результатом. В итоге, правда, все это ему не помогло, поэтому давайте посмотрим, как можно модернизировать его подход, чтобы уберечь систему от угроз.

1️⃣Идея минимизации — отличная, берем как есть. Кощей поместил свою смерть на кончик иглы, и мы сделаем доверенную кодовую базу системы как можно меньше.
2️⃣С изоляцией компонентов у Кощея что-то пошло не так: все они были по-своему уязвимы, и каждый «подставлял под удар» следующий. Мы изолируем компоненты системы друг от друга, но обойдемся без принципа матрешки.
3️⃣Система контроля у Кощея вообще дала сбой — не знаем, как он там берег свой дуб, но атаку на сундук и на все его внутренние компоненты прозевал. Мы поступим иначе — будем тщательно контролировать все взаимодействия процессов в системе.

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

Вот и получается, что история про способность Кощея Бессмертного избегать смерти — это буквально сказка о кибериммунитете.

❔А какие сказки или фильмы, иллюстрирующие принципы кибериммунитета, вы можете вспомнить?

«А где и что тогда прячет/защищает «иглу»? :) нужна визуализация и пояснительная бригада :)» — спросил нас подписчик.

Начало истории о Кибериммунитете в русских сказках читать тут 👈

Отвечает Александр Друзь Сергей Соболев, старший архитектор по информационной безопасности «Лаборатории Касперского»:

Предлагаем пофантазировать вместе, как нам выстроить альтернативную архитектуру защиты Кощеевой иглы 🪡!

Итак, наше ТЗ:
1️⃣ сформировать и минимизировать поверхность защиты;
2️⃣реализовать изоляцию компонентов;
3️⃣реализовать контроль взаимодействия.

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

Видимо, при моделировании угроз профиль атакующего предполагал только каких-то случайных животных и иных персонажей с базовой экипировкой (например, чтобы медведь 🐻 не сломал сундук или любопытный малыш, собирающий грибы-ягоды, не стал начинающим взломщиком). А вот целевые атаки, подготовленными спецами с топовым инструментом (мечом-кладенцом), почему-то не были оценены серьёзно, что Кощея в итоге и сгубило.

🤓 Заметьте, Кощей реализовал некую защиту периметра (сундук), но этот сундук не выдержал атаки грубой силой 🤺.

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

Что же делать?
Вернуться к принципам и ключевым этапам кибериммунной разработки!

1️⃣Определить ключевые активы и ущербы: это, очевидно, жизнь Кощея и его смерть в результате критического повреждения иглы.

2️⃣Определить контекст: Кощеево царство, Кощей, игла, беспроводная связь неограниченного радиуса действия между этими сущностями.

3️⃣Определить цели безопасности:
🟢ЦБ1. При любых обстоятельствах сохраняется целостность иглы.

4️⃣Определить предположения безопасности:
🟢ПБ1. Защищаемый субъект (Кощей) находится в трезвом уме и твёрдой памяти, хочет жить вечно.

5️⃣Определить «доверенную вычислительную базу»:
🟢ДВБ, очевидно, — это сама игла.
А вот ни сундук, ни заяц, ни утка с яйцом в ДВБ не входят, их защита нам малоинтересна.

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

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

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

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

PS: как думаете, а для чего нам было нужно предположение безопасности №1? 🙃

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