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: возможно, стоит ввести и второе предположение безопасности, относящееся к контексту: местность, где закопана игла, должна являться сейсмобезопасной. Хотя в русских сказках отсутствуют предпосылки для вулканической деятельности, которые могут обнулить все старания Кощея по закапыванию своей прелести 😁.

✅ Безопасная байка №1: Как взламывают лифтовое оборудование?

Без официоза, без занудства, но с фокусом на конкретные вопросы из сферы конструктивной безопасности — в нашем новом формате коротких и содержательных видео о B2B человеческим языком 😍.

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

Если вы работаете с инфраструктурой, строительством, промышленными объектами или просто хотите понимать, как обеспечивается реальная безопасность на объектах — эти видео для вас.