Кибериммунная разработка

В тридевятом царстве старость считали не столько болезнью, сколько архитектурным долгом: чем дольше живёт государство, тем больше в нём накопленных решений «на потом». Царь-батюшка однажды объявил цель безопасности царства: при любых обстоятельствах (легитимный правитель принимает молодильное яблоко из проверенной поставки) происходит восстановление сил с сохранением жизни, полномочий управления и памяти о ключевых указах. Для этого в дальнем саду на острове выращивали молодильные яблоки — единственный компонент, который восстанавливал силы без перезагрузки престола. Сад принадлежал Кощею, но яблоки официально сертифицировал Регулятор: на каждом плоде — восковая печать, на грузовых листах — номер партии, в паспорте сада — заклинание целостности. Цепочка поставки была длинной, зато «прозрачной на словах»: сад → сборщик → лодочник → купец → дворцовый кладовщик → повар → царский стол. На каждом звене принимали груз по внешнему виду: яблоко красное, блестит, печать не сорвана — значит, «то самое». Происхождение спрашивали редко: *«Купец же привёз, а купец не станет врать — ему выгодно»*. Это и было главное предположение безопасности, которое никто не зафиксировал в ТЗ. Между тем в среднем звене — у купца с лавкой у пристани — жил его двоюродный племянник, человек без злого умысла, но с сильной транзитивной зависимостью от чужого дохода. Он не ломал сад и не подделывал печать Регулятора. Он сделал хуже и тоньше: подменил часть партии — три яблока из корзины заменил на такие же на вид, но с другого дерева: с соседней грядки, куда когда-то случайно упало семя «быстрого омоложения» без проверки состава. Внешне — те же яблоки. Печать купец переставил с настоящих на подменные, потому что «иначе не примут на дворе». В перечне состава царства, если бы он существовал, по-прежнему значилось: молодильное-яблоко v1.0, поставщик=Сад-Кощея, сертифицировано=да. А фактически в корзине оказался смешанный релиз. Царь съел яблоко. Молодость вернулась — но желаемое состояние по цели безопасности не наступило: сила есть, а память о важных указах — рваная, решения — импульсивные, доверие к советникам — как к непроверенным библиотекам из чужого репозитория. Дворцовые врачи назвали это «усталостью». Регулятор назвал это «инцидентом эксплуатации». А старый дед у кладовой, единственный, кто вёл журнал приёмки по звеньям, прошептал: «Печать была, а цепочка доверия — нет».

А помните мы рассуждали о кибериммунитете в русских сказках, а именно что общего у кибериммунитета и смерти Кощея на конце иглы*? Мы решили продолжить тему 😎, тем более, что в русских сказках есть и скрытый СКИБ-смысл! ✔️ Царевич сжёг лягушачью кожу как «лишнюю прослойку интерфейса». На языке СКИБ он не ускорил интеграцию, а разрушил безопасный режим перехода: публичный облик, внутреннее состояние и политика смены контекста оказались связаны устным запретом. Сказка честно показывает, что самый дорогой баг — это оптимизация до понимания инварианта. ✔️ Колобок решил, что доверие можно оформлять песней: каждому контрагенту один и тот же публичный интерфейс, никакой проверки контекста, зато прекрасная доступность. Лиса не атаковала криптографию; она просто стала первым клиентом, который прочитал спецификацию как пользователь, а не как автор. 🫡 * Подробный разбор "где и что тогда прячет/защищает «🪡 иглу»" мы тоже уже делали.

🤓 Важнейшим элементом систем с конструктивной информационной безопасностью является согласованность целей и предположений безопасности (ЦПБ). ➡️Цели безопасности (ЦБ) входят в зону ответственности разработчика целевой системы. ➡️Предположения безопасности оговаривают условия, в который разработчик может обеспечить поставленные ЦБ. Важно, что ПБ не «висят в воздухе» — они обязательно должны стать ЦБ какой-то другой системы и, соответственно, за каждое предположение безопасности тоже должен кто-то отвечать.

‼️Это важно: разработчик отвечает за цели безопасности, только если выполнены согласованные с заказчиком предположения безопасности.

Нарушение согласованного с заказчиком предположения безопасности снимает с разработчика ответственность за нарушение одной или нескольких целей безопасности целевой системы. Поэтому важно обеспечить связность и полноту ЦПБ для межсистемном уровне. Совсем как в нашей головоломке на картинке 🙃

Давно не рассказывали про наш проект в СПбГУ, где студенты учатся проектировать кибериммунные системы на примере беспилотников. Исправляемся 🫡 Поехали! 📈 Статус: движемся вперед Да, не так быстро, как хотелось бы. Но прогресс есть: — разработчики наконец интегрировали свои наработки; — виртуальные дроны уже выполняют первые пробные полеты. При этом даже в учебном проекте – все как в большой реальности 🫣: нормативная база пока не готова, сертификационный базис — тоже. Регулятор доделывает скрипты для сертификации. Поэтому наши дроны летают как бы в ЭПР — экспериментальных правовых районах. То есть без сертификатов. Но у них уже есть цели безопасности, а у некоторых — ещё и реализованные шаблоны СКИБ (мониторы, выделенные механизмы защиты). …и это только симуляция (пока). Вся система — в docker-контейнерах, код на Python и немного на Go. ‼️Ключевой нюанс про доверенный код «Доверенный код» в кибериммунной разработке — это любой код, который влияет хотя бы на одну цель безопасности системы. А домен безопасности — это единица изоляции. Весь код внутри домена имеет одинаковый требуемый уровень доверия. И вот разработчики пошли стандартным путем: при сборке docker-образа они копируют весь код системы (включая все домены), а потом запускают только нужный python-файл для конкретного домена.

❓ Вопрос к вам Какой процент кода в такой сборке окажется критичным (доверенным) для целей безопасности? Голосуйте с помощью эмодзи: 👍 — 0% — ничего страшного, можно так и оставить 🧐 — 50% — половина совсем зря доверяет 👎 — 100% — вся система становится потенциально небезопасной

Твой первый шаг в освоении кибербезопасности💡 Студенты 1-2 курсов колледжей и вузов, идём к вам с новой возможностью для обучения — нашим бесплатным онлайн-курсом «Введение в кибербезопасность». Что в программе? 1️⃣Основные понятия в ИБ 2️⃣Инструменты атакующих, виды кибератак 3️⃣Сферы информационной безопасности и роли в ИБ 4️⃣Конструктивная безопасность 🛡Все темы курса объяснили для вас наши эксперты — просто, понятно, с примерами, в формате коротких видео. А после просмотра можно закрепить пройденный материал и пройти тестирование. Чтобы получить доступ к курсу, оставьте заявку, указав вашу академическую почту (с доменом университета/колледжа). Полученные знания пригодятся вам и в личной, и профессиональной жизни!🤗

Конечно, это 💯. Но напомнить основы — никогда не лишнее 😉

Друзья! Мы хотим оставаться с вами на связи, а потому вот наши новые площадки 👮‍♂️ Мы — ВКонтакте 💩 И в MAX — мы тоже теперь есть! Этот канал в ✈️ продолжает свою работу, но, если вам удобнее читать нас на других платформах, будем рады видеть ❤️.

🌟 Диплом, практика или 100 000 рублей: как работают CPI баллы CPI (Cyberimmunity Progress Items) — это система поощрения от «Лаборатории Касперского» всех заинтересованных в теме конструктивной информационной безопасности и кибериммунной разработки за вклад в развитие концепции кибериммунитета. Простыми словами: мы начисляем баллы за дополнительное обучение, которое вы проходите по теме кибериммунной разработки, за участие в олимпиадах и хакатонах, научные выступления и публикации по теме кибериммунитета. Каждый ваш вклад (от удачного доклада или защиты диплома по теме кибериммунной разработки до участия в инженерных соревнований или ВУЗовской олимпиаде) оценивается CPI-баллами. Это прозрачный способ измерить вашу активность и пользу для технического сообщества. Логика простая: чем выше уровень мероприятия или журнала, тем больше баллов. Виртуальные CPI баллы дают вполне реальные бонусы: 🔸 Студентам — выбрать тему диплома и писать его при поддержке специалистов «Лаборатории Касперского». Мы помогаем с каркасом, методологией, даём отзыв и рецензию. Возможна совместная публикация. 🔸 Опытным специалистам — приоритетный отбор на оплачиваемые задачи от сообщества. 🔸 В 2025 году топ самых активных членов сообщества по сумме CPI баллов получили по 100000 рублей каждый. Вот и получается, что Олимпиада — это не только крутая задача и шанс заявить о себе. Это ещё и вклад в вашу личную копилку CPI баллов. Участвуете — зарабатываете. Всё честно. Вопросы по CPI смело задавайте в комментариях 👇

👨‍💻 «Лаборатория Касперского» совместно с Кафедрой информатики УГГУ запускают регистрацию на II Всероссийскую олимпиаду по кибериммунной разработке. Что нужно сделать? Спроектировать кибериммунную архитектуру автономной буровой установки в сценарии «цифровой рудник». Звучит сложно? Возможно, но будет точно интересно! Кто может принять участие? Студенты ВУЗов, колледжей или школьники от 16 лет. Достаточно базового знания Python — остальное вы узнаете на занятиях. 🗓 Ключевые даты олимпиады:

27, 30 апреля и 5 мая в 16.00 (GMT+3, Мск) — обучение по основам кибериммунной разработки 10 мая — последний день регистрации 11 мая — мит-ап по задаче олимпиады с 16 мая (8:00) до 17 мая (16:00) (GMT+3, Мск) — проведение олимпиады 20 мая — объявление результатов

Регистрация ➡️ ПО ССЫЛКЕ 🔗 Подробную информацию и регламент вы найдете тут.

🛸 Представьте, что над городом летают БПЛА с автопилотом. Они привозят еду из ресторанов, лекарства из аптек, мелкие интернет-заказы. Наблюдают за дорожным движением, проверяют состояния мостов, трубопроводов, линий электропередач или ищут незаконные свалки. А, может, проводят аэросъемку для новостей. Они нужные и полезные. И крайне удобные! Но возникает вопрос безопасности 🤔. Несмотря на то, что аппараты эти сложные, — собираются БПЛА часто из того, что подешевле и легче достать. Они получают команды по радиоканалу, да еще и обновляются «по воздуху», иногда через открытые интерфейсы, обмениваясь данными с наземными серверами. А это значит: 👎 прошивку в целом или какие-то компоненты могут скомпрометировать (подменить/подправить); 👎 полётное задание исказить 👎 канал связи — перехватить или заглушить; 👎 сам БПЛА — угнать или заставить упасть на толпу. Поэтому обществу важно быть уверенными не только в надежности фирмы-производителя, но и смотреть глубже — можно ли доверять конкретной связке «прошивка + БПЛА»: не подменили ли код, не слабое ли «железо», хватит ли защиты, если что-то пойдёт не так. Но как убедиться в безопасности этой связки? Кто должен дать нам гарантию? 🤷🏻‍♂️ И вот тут в нашей картине мира появляется его величество РЕГУЛЯТОР — служба, которая по понятным правилам проверяет пакет разработчика: 🟢что внутри программы; 🟢насколько сложно убедиться в безопасности ключевой части системы; 🟢пройдены ли автоматические проверки. В основе — ГОСТ Р 72118-2025 Именно он описывает, как проектировать системы, чтобы безопасность была заложена в конструкцию изначально, а не исправляла ошибки «по факту». И тут ключевой момент — цели безопасности (ЦБ). Регулятор не просто смотрит «есть защита или нет». Он проверяет: совпадают ли заявленные цели с реализованными свойствами системы. И затем фиксирует эти ЦБ в сертификате. Зачем это нужно? Потому что ЦБ — это не строчка в отчёте. Это фундамент, который определяет: — как устроена архитектура дрона; — какой код считается критичным; — какие проверки обязательны, а какие — опциональны. Сертификат становится публичным документом: «вот дрон, вот его прошивка, вот владелец, и вот что этот дрон гарантирует с точки зрения безопасности». Если в реальности дрон ведёт себя не так, как обещано в ЦБ, — сертификат отзывается. Как бракованный товар. Стоимость сертификации напрямую зависит от сложности и размера доверенной вычислительной базы, обеспечивающей заявленные цели безопасности. При этом хороший регулятор не раздувает ни цену допуска, ни цену жизни с техникой. Он подталкивает защищать главное — людей, инфраструктуру, среду — без лишних затрат: меньше бессмысленных проверок, меньше сюрпризов в эксплуатации. #ГОСТ72118 #СКИБ #ОтрасльКакСКИБ

Итак, мы остановились на том, что безопасность дронов невозможно проверить «на глаз» — нужен регулятор и чёткие правила... И вот тут в нашей картине мира появляется его величество РЕГУЛЯТОР — служба, которая по понятным правилам проверяет пакет разработчика: 🟢что внутри программы; 🟢насколько сложно убедиться в безопасности ключевой части системы; 🟢пройдены ли автоматические проверки. В основе — ГОСТ Р 72118-2025 Именно он описывает, как проектировать системы, чтобы безопасность была заложена в конструкцию изначально, а не исправляла ошибки «по факту». И тут ключевой момент — цели безопасности (ЦБ). Регулятор не просто смотрит «есть защита или нет». Он проверяет: совпадают ли заявленные цели с реализованными свойствами системы. И затем фиксирует эти ЦБ в сертификате. Зачем это нужно? Потому что ЦБ — это не строчка в отчёте. Это фундамент, который определяет: — как устроена архитектура дрона; — какой код считается критичным; — какие проверки обязательны, а какие — опциональны. Сертификат становится публичным документом: «вот дрон, вот его прошивка, вот владелец, и вот что этот дрон гарантирует с точки зрения безопасности». Если в реальности дрон ведёт себя не так, как обещано в ЦБ, — сертификат отзывается. Как бракованный товар. Стоимость сертификации напрямую зависит от сложности и размера доверенной вычислительной базы, обеспечивающей заявленные цели безопасности. При этом хороший регулятор не раздувает ни цену допуска, ни цену жизни с техникой. Он подталкивает защищать главное — людей, инфраструктуру, среду — без лишних затрат: меньше бессмысленных проверок, меньше сюрпризов в эксплуатации. #ГОСТ72118 #СКИБ #ОтрасльКакСКИБ #AI_СКИБ

🛸 Представьте, что над городом летают БПЛА с автопилотом. Они привозят еду из ресторанов, лекарства из аптек, мелкие интернет-заказы. Наблюдают за дорожным движением, проверяют состояния мостов, трубопроводов, линий электропередач или ищут незаконные свалки. А, может, проводят аэросъемку для новостей. Они нужные и полезные. И крайне удобные! Но возникает вопрос безопасности 🤔. Несмотря на то, что аппараты эти сложные, — собираются БПЛА часто из того, что подешевле и легче достать. Они получают команды по радиоканалу, да еще и обновляются «по воздуху», иногда через открытые интерфейсы, обмениваясь данными с наземными серверами. А это значит: 👎 прошивку в целом или какие-то компоненты могут скомпрометировать (подменить/подправить); 👎 полётное задание исказить 👎 канал связи — перехватить или заглушить; 👎 сам БПЛА — угнать или заставить упасть на толпу. Поэтому обществу важно быть уверенными не только в надежности фирмы-производителя, но и смотреть глубже — можно ли доверять конкретной связке «прошивка + БПЛА»: не подменили ли код, не слабое ли «железо», хватит ли защиты, если что-то пойдёт не так. Но как убедиться в безопасности этой связки? Кто должен дать нам гарантию? 🤷🏻‍♂️

Попробуйте предположить в комментариях 👇 Есть ли у вас рабочие варианты? (Прилетят инопланетяне и всех спасут — как рабочий вариант не принимается 😁)

🔥 Победить студентов из Москвы и Екатеринбурга? Реально, если учиться правильно! 7 апреля на конференции RUSCADASEC прошла «Студенческая битва» по информационной безопасности АСУ ТП. Сражались команды из: — Губкинского университета (Москва) — МИРЭА (Москва) — УрФУ (Екатеринбург) — ЧувГУ (Чебоксары) Вопросы были сложные, оценивали эксперты конференции. И победила… команда из Чебоксар 🏆

Давайте честно: многие привыкли думать, что топовые IT-специалисты готовятся только в столицах. Но этот кейс показывает обратное 😜.

Ребята из ЧувГУ учатся на факультете информатики и вычислительной техники (09 УГСН), и при этом уже имеют реальный практический опыт в компании iGridis (технологический парк Чувашии). И вот здесь — главный вывод для всех, кто сейчас учится или только выбирает путь: мы часто говорим о кибериммунной разработке и конструктивной ИБ как о будущем. Но будущее уже наступило. Студенты, которые со скамьи: 🟢понимают цели безопасности; 🟢умеют проектировать системы с защитой в архитектуре; 🟢имеют реальную практику у работодателей, которые ценят такой подход, — становятся не просто выпускниками, а востребованными специалистами. И этот кейс — прямое подтверждение. Пока одни только сдают экзамены, другие уже выигрывают всероссийские соревнования и получают офферы. Рынок IT меняется. Обычных «кодеров» скоро заменят ИИ. А вот системных инженеров, которые умеют думать о безопасности на уровне архитектуры, будут ценить всё больше. И работодатели это уже видят. iGridis — не исключение, а тренд. Поздравляем ребят 🤝 А всем, кто хочет быть на их месте через год-два — обращайте внимание на кибериммунные компетенции. Это не просто «умные слова», а реальный билет в профессию. Ваша команда КИБ 😎

👍👍👍👍🚀 На сайте KasperskyOS открыли раздел «Исследования»

KasperskyOS — микроядерная операционная система нового поколения, созданная с нуля в «Лаборатории Касперского». Благодаря принципам, заложенным в ее архитектуру, на основе нашей ОС можно создавать решения, обладающие кибериммунитетом — встроенной защищенностью от подавляющего большинства видов кибератак. Подробнее — на сайте https://os.kaspersky.ru/

Опубликованные статьи — результат совместной работы «Лаборатории Касперского» и ИСП РАН в области конструктивной информационной безопасности (КИБ). В «Исследованиях» собраны: 🟢научные публикации — формальные модели, методы верификации, доказательная база KasperskyOS; 🟢технические статьи разработчиков — как принципы КИБ реализованы в микроядерной ОС и решениях на её основе. Проще говоря: то, о чём мы говорим в канале, теперь можно почитать в одном месте — с фундаментальной наукой и практическими примерами. И применительно к нашей KasperskyOS 😎 🔐 Кому пригодится: архитекторам, ИБ-специалистам, разработчикам, аналитикам — всем, кто проектирует защищённые системы. А также студентам и тем, кто хочет копнуть глубже.

😁😆😁 рассказать о том, что на сайте KasperskyOS появился раздел «Исследования»...

🔗 Цепочка поставок — ваше слабое звено. И с каждым годом оно становится только опаснее Мы привыкли проверять свой код. Но как часто вы проверяете код библиотек, npm-пакетов, расширений VS Code, инструментов сборки? А зря. Атаки на цепочку поставок уже давно перестали быть «теоретической угрозой» и стали повседневностью. Вот лишь несколько самых примечательных инцидентов прошлого года: 💥 Ограбление Bybit на $1,5 млрд Злоумышленники скомпрометировали ПО криптокошелька Safe{Wallet} и вместо обычной транзакции перевели активы на свои счета. 💥 Червь Shai-Hulud 2.0 Самораспространяющийся зловред, который искал в системах разработчиков секреты (токены, ключи, пароли) и публиковал их в открытых GitHub-репозиториях. Итог: 400 000 утекших секретов и кража крипты у пользователей Trust Wallet на $8,5 млн. 💥 Вредоносные npm-пакеты с 2,6 млрд загрузок в неделю Злоумышленники внедрили криптостилер в такие популярные пакеты, как chalk и debug. Увы, техническая ошибка не позволила им украсть больше $925 — но кто даст гарантию, что в следующий раз не получится? 💥 Атака на провайдера MSP через SimpleHelp Вымогатели DragonForce проникли в инфраструктуру поставщика управляемых услуг через необновлённые уязвимости и распространили шифровальщик среди клиентов. 💥 GlassWorm в экосистеме VS Code Червь заражал расширения Visual Studio Code, воровал GitHub-токены, криптокошельки и использовал Google Calendar как командный центр. И это только вершина айсберга. 🧊 👉 Самые примечательные атаки на цепочку поставок в 2025 году — читайте в блоге «Лаборатории Касперского». Рекомендуем к изучению всем, кто проектирует, разрабатывает или использует ПО с открытым кодом и сторонними компонентами. Что это значит для разработчиков и бизнеса? Классический подход «мы доверяем поставщику» или «эта библиотека популярная, значит, безопасная» — больше не работает. Вы можете написать идеальный код, но если вы подтягиваете через npm скомпрометированный пакет, ваша система становится уязвимой. 🔐 И здесь на сцену выходит конструктивная информационная безопасность (КИБ): ▪️ Цели безопасности закладываются в архитектуру с самого начала. ▪️ Система не доверяет своим подсистемам — даже «родным». ▪️ Код проверяется, компоненты верифицируются, а критичные функции изолируются. ГОСТ Р 72118-2025 (методология проектирования СКИБ) даёт конкретные шаблоны и подходы, как строить системы, устойчивые к различным кибер-атакам, включая атаки на цепочки поставок. Потому что доверять всем подряд — это не стратегия.