KasperskyOS

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️⃣— Почему бабушкин забор — это кибериммунитет? Джун вертел в голове идею минимизации. «Хорошо, сервисы должны делать только то, что нужно. Но ведь всё равно уязвимости будут. Что тогда?» Он вспоминал, как баги прокрадывались даже в самые простые правки, как система ломалась из-за одной строчки кода. — А если баг уже есть? Что тогда? — спросил он вслух. Сеньор улыбнулся и откинулся на спинку стула: — Ты ездил к бабушке в деревню? — Эм… да. А при чём тут это? — Ты пытался зайти во двор через забор? — Ну… да, но там же была дыра. — И что случилось? Джун поморщился от воспоминаний: — Меня атаковал петух. DevOps прыснул со смеху: — Вот и ответ. Забор у бабушки дырявый, но во двор не зайдёшь. Секьюрити ресёрчер кивнул: — Вот это и есть эшелонированная защита. Дыра в заборе — это баг в коде. А петух — это система защиты, которая не даёт его использовать. IDS. Очень проактивный. Безопасник задумчиво посмотрел в потолок. — Получается, в нашем проде сейчас нет даже забора, не говоря уже о петухах? DevSecOps пожал плечами: — У нас забор, который открывается по нажатию кнопки. В котором ещё и дефолтный пароль admin. Сеньор усмехнулся, а секьюрити ресерчер продолжил аналогию: — Ну, в реальной жизни никто так не делает. Ты можешь найти лазейку, но бабушка уже ждёт тебя с поленом, а дед — с берданкой. Это DDoS mitigation, ручной. Layer 8 Security. Джун вдруг понял: — Значит, кибериммунитет — это не про отсутствие багов. Это про то, чтобы баги не могли привести к катастрофе? Секьюрити ресёрчер улыбнулся: — Именно. Минимизация. Изоляция. Контроль. Даже если у тебя есть баг, система не должна рушиться. Безопасник кивнул: — Как с British Airways в 2017. У них ошибка при обновлении центра обработки данных вызвала массовый сбой. Все рейсы отменили, хаос, убытки в сотни миллионов фунтов. Если бы инфраструктура была изолирована и критичные процессы защищены, всё могло бы ограничиться локальным сбоем. Джун задумался. «Значит, даже если мой код дал сбой, система должна выстоять?» Он не знал, почему, но чувствовал, что это — важный момент. Секьюрити ресёчер не зря каждый раз твердит мантру «Минимизация. Изоляция. Контроль». Продолжение следует...

Вынос пользы для джуна:| ▪️Эшелонированная защита — это надёжность. Если одно звено системы сломалось, следующая линия обороны должна его остановить. ▪️Изоляция критичных сервисов снижает ущерб от сбоев. Баги неизбежны, но их последствия можно ограничить. ▪️Fail-safe подход: система должна продолжать работать даже в случае сбоя, а не рушиться целиком. ▪️Смотри шире: ошибка в обновлении центра обработки данных не должна приводить к полному коллапсу бизнеса.

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

British Airways (2017): сбой при обновлении ЦОД вызвал массовые отмены рейсов, из-за отсутствия отказоустойчивой инфраструктуры. Убыток — £150 млн., свыше 75000 человек пострадали от задержек рейсов. Подробнее читай тут. Defense in Depth (эшелонированная защита): концепция многослойной безопасности, когда даже если один уровень защиты взломан, есть следующий. Fault Isolation (изоляция отказов): чтобы единичный сбой не приводил к полному отключению системы. Например, аварийное отключение одного узла не должно рушить весь дата-центр. Graceful Degradation: при сбоях система должна работать в ограниченном режиме, а не полностью отключаться. DDoS mitigation: набор методов управления сетью и/или инструментов для противодействия или смягчения воздействия распределенных атак типа «отказ в обслуживании» на сети, подключенные к Интернету. Layer 8 Security — это теоретический уровень модели OSI, находящийся на её вершине и обозначающий «пользовательский» или «политический» уровень.

💬 Пиши в комменты: какая самая абсурдная мера защиты реально спасала вашу систему? Ставь 👍, если работаете на уровне Layer 8. #поиграемвКИ

📎 Мини-курс «Кибериммунитет за 3 вечера». 📆 СТАРТ — 10 июня в 19:00 по Мск. ✅Для истинных кодеров. Без сахара, ванили и хрупких систем. ✅Для тех, кто видит TODO в легаси-коде и понимает, что его никто не исправит. ✅Для тех, кто не просто пишет код, а понимает, что за ним стоит. Присоединяйся к команде. 🔘https://vk.cc/cKFXlQ Мы взлетаем 🚀✨✨✨ #поиграемвКИ Ставь 👍, если ты с нами!

Чайник не должен уметь ломать прод! #поиграемвКИ

2️⃣— Чайник с рутовыми правами Офис ожил. Серверы гудели, DevOps что-то колдовал в терминале, а безопасник уже строчил отчёт «Почему так случилось, и кто виноват». Джун задумчиво сидел перед ноутбуком: «Если изоляция такая важная, почему её не делают по умолчанию?» Он машинально открыл Telegram и увидел новость: «Хакеры взломали умные чайники и устроили DDoS-атаку». — Сеньор, тут чайники взломали. Как? Сеньор даже не удивился: — Очень просто. У чайника были рутовые права. Джун моргнул: — Чайник. С root-доступом. Ты серьёзно? DevSecOps хмыкнул: — Ага. Потому что кто-то решил, что чайнику вдруг пригодится полный контроль над всей сетью. — То есть, чайник — это как наш прод, где API комментариев умеет дропать базу? Секьюрити ресёрчер кивнул. — В точку. Минимизация — важнейший принцип безопасности. Чайнику не нужно управлять маршрутизатором. Сервису логов не нужен доступ к API платежей. — Но иногда ведь удобно, если сервисы могут больше? — Конечно, удобно... Так же, как удобно носить ключи от всех дверей дома в одной связке и терять их на автобусной остановке. DevOps грустно посмотрел в монитор и вспомнил факт их прошлого: — В 2016 году Mirai-ботнет устроил крупнейшую атаку, потому что устройства имели дефолтные пароли и слишком много прав. Камеры наблюдения превратились в оружие хакеров. — А что нужно было сделать? Сеньор ответил без раздумий: — Least Privilege. Минимальные права. Default Deny. По умолчанию запрещено всё, разрешается только строго необходимое. Джун покачал головой, не понимая: — Получается, мой умный чайник — умнее моего кода? Он хотя бы кипятит воду и не пытается получить root-доступ? Секьюрити ресёрчер усмехнулся: — Если ты не напишешь код правильно, он может и это начать делать. Продолжение следует...

Вынос пользы для джуна: ▪️Минимизация прав — меньше атак. Если сервис умеет только то, что нужно, его сложнее взломать. ▪️Default Deny — безопасность по умолчанию. Если ты не задал явные права, у процесса их нет. ▪️Least Privilege — у каждого сервиса только необходимые полномочия. Если API комментариев не должен менять данные в биллинге, то он и не должен их иметь. ▪️Нельзя проектировать системы по принципу «а вдруг пригодится». Не давай чайнику права root!

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

Mirai-ботнет (2016): использовал устройства с дефолтными паролями, превращая их в часть ботнета. В результате были атакованы крупные сервисы, включая Twitter, Netflix и GitHub. Подробнее читай тут. Least Privilege: система должна работать по принципу «минимально необходимых прав». Это особенно критично в облаках и контейнерных средах. Default Deny: если не знаешь, нужно ли что-то разрешить — запрещай по умолчанию. В сетевых политиках (например, firewall) это ключевая практика. RBAC (Role-Based Access Control): настройка прав доступа через ролевую модель — только необходимое.

Ставь 😂, если хочешь себе такой чайник. Ставь 👍, если у тебя сервис имел прав больше, чем должен был. #поиграемвКИ

Изоляция — это когда хотя бы серверная жива... #поиграемвКИ

1️⃣— Мир на костылях Жара стояла такая, что даже серверная дышала с трудом. В командном чате горело: «Критическая ошибка!», «Сломалось всё!», «Кто последний коммитил?!», «Бэкапы работают?», «Роллбек не помогает!» Джун уставился в монитор, пытаясь глазами оживить графики мониторинга. Сердце колотилось: это его код ушёл в прод вчера ночью. Всё было нормально… Или нет? Сеньор пил кофе и молча листал логи. Безопасник мрачно снимал скриншоты ошибок. DevOps вызывал древних богов Ansible. DevSecOps что-то шептал про «почему опять без авторизации?». «Джун, дыши», — сказал себе наш герой, но сердце гремело, как перегруженный процессор. — Но ведь тесты были зелёные! Всё работало! — наконец выдавил он вслух. Сеньор лениво поднял бровь: — На тестах оно и у бабушки работает. А в проде законы физики другие. Джун сглотнул. В проде всё будто жило своей жизнью. Безопасник оторвался от экрана: — О, опять API платежей развалилось? Как неожиданно... DevOps нервно хохотнул: — Да, причём из-за фикса в комментариях. — Это как? — переспросил Джун. — Он как бабушкин дом — один угол чихнёт, второй осыпается. А что ты хочешь? Монолит... В этот момент в офисе погас свет. Только серверная горела индикаторами, как маяк в ночи. Сеньор нахмурился: — Вот это и есть изоляция. Серверная на отдельной линии. А у нас в коде почему-то всё завязано друг на друге, как гирлянда в новогоднем коробе. Секьюрити ресёрчер, наблюдавший за всем из угла, наконец заговорил: — Именно. Кибериммунитет — это не про отсутствие багов. Это про устойчивость. Минимизация. Изоляция. Контроль. Джун моргнул. Он чувствовал, что сейчас узнает что-то важное. — При чем тут кибериммунитет? Почему вдруг мы об этом заговорили? Сеньор многозначительно заявил: — Кибериммунитет — ключевой элемент безопасных IT‑систем будущего. Как иммунитет защищает организм от болезней и инфекций, кибериммунитет направлен на обеспечение устойчивой и адаптивной защиты цифровых систем. И продолжил: — Но для этого надо понять, как всё устроено на самом деле. Например, на курсах по кибериммунной разработке. Кстати, подумай об этом. Рекомендую отличный вариант [ссылка на курс по КИ]. Сам в своё время проходил. Продолжение следует...

Вынос пользы для джуна: ▪️Понимай, как твоя система ломается. Если не знаешь, как и где она может упасть — это уже проблема. ▪️Минимизируй точки отказа. Если сервис не влияет на другой, его падение не должно нести критические последствия. ▪️Изолируй критичные зоны. Серверная в офисе выжила, потому что её заранее сделали отдельной. Код должен проектироваться так же. ▪️Думай, как защитить систему от самой себя. Иногда самый опасный враг продакшена — это код, который писали сами разработчики.

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

Монолит vs Микросервисы: монолитные системы часто страдают от эффекта «домино»: один сбой тянет за собой всю систему. В микросервисной архитектуре это частично решается, но без строгой изоляции проблемы всё равно распространяются. Изоляция через Fault Domains: в продвинутых системах компоненты распределяют так, чтобы сбой одного не рушил всё. Это как раз то, что есть в дата-центрах, но редко в коде. Assume Failure: критические сервисы проектируются так, будто сбой неизбежен. Например, серверная на отдельной линии электропитания, как в примере. Изоляция в коде: использование контейнеров (Docker, Kubernetes), политики доступа (RBAC, IAM), чёткое разграничение сервисов.

Ставь 😭, если ты валил когда-нибудь прод и понимаешь всю боль джуна. Ставь 👍, если понравилось начало нашей игры в кибериммунитет! #поиграемвКИ

«Чтобы завоевать доверие, нужна вечность, для разочарования достаточно одного мига», — забавно, что эта фраза, напоминающая цитату из какой-нибудь 147-й серии бесконечной мыльной оперы, очень точно описывает важную проблему создания кибербезопасных систем. Если мы не докажем, что реализованные в системе функции безопасности работают корректно, то доверия быть не может. Для доказательства разработано множество процедур анализа кода (например, статический и динамический анализ кода, фаззинг-тестирование, формальная верификация, тестирование на проникновение), методов и инструментов — от простых и хорошо известных до очень сложных, редко используемых и требующих специальных компетенций. Несмотря на всю зрелость методов, есть важная проблема: неясно, как грамотно и осознанно поделить код на тот, который надо проверять «задешево», и тот, который надо проверять «задорого». В результате для доказательства доверия к системе возникает потребность тщательно проверять чуть ли не весь ее код, что, конечно, почти невыполнимо на практике. Решить эту проблему можно, следуя принципу минимизации доверенной кодовой базы. Смысл принципа в том, чтобы предельно уменьшить объем кода, критичного для безопасности системы. Тогда «дорогие» методы проверки нужно будет применить не для всего кода, а только для небольшой его части, тем самым значительно снизив затраты на анализ. Для остального же будет достаточно и базовых процедур. На прикладном уровне принцип минимизации доверенной кодовой базы сводится к следующему: 🟢 как можно меньше доверенных компонентов должны непосредственно влиять на достижение целей безопасности системы; 🟢 сами доверенные компоненты должны быть достаточно простыми с точки зрения функциональности и иметь маленькую поверхность атаки. На системном уровне: 🟢 должно быть как можно меньше кода, сосредоточенного в ядре безопасности операционной системы (оно состоит собственно из ядра ОС, монитора обращений и некоторых других модулей). Именно этот принцип помогает разрабатывать кибериммунные системы.

Прод горит, а код еле держится «на костылях»? Значит, это самое время выпить кофе переключиться и принять участие в игре, от которой зависит не только твой скилл, но и, возможно, будущая карьера! Поиграем в кибериммунитет? 🙃 Ничего не понятно, но очень интересно! 📆 Стартуем в понедельник 28 апреля на нашем канале KasperskyOS. Разработка. Что тебя ждёт во II Эпизоде? ▪️Реальные фейлы мирового масштаба: от British Airways до Tesla и Equifax. Разберём, почему это случилось, и как этого избежать в твоём коде. ▪️Кибериммунитет на пальцах: даже бабушкин петух умеет строить эшелонированную защиту лучше, чем специалисты многие компании. Поймёшь, почему. ▪️Жёсткие холивары и прикольные шутки с DevSecOps и безопасниками: узнаешь, почему чайнику не нужны рутовые права, и зачем думать, будто тебя уже взломали (спойлер: потому что, скорее всего, так и есть). ▪️Разделы «Вынос пользы для джуна» и «Пояснительная бригада», в которых всё, что нужно и важно, причем кратко и ёмко. ❓ Почему мы крайне рекомендуем потратить несколько минут в день на нашу игру. Потому что твой код уже давно не только твоя задача. От него зависит как твоя зарплата, так и уважение команды, и твоя будущая карьера. Научишься применять кибериммунный подход к разработке — станешь человеком с которым реально советуются сеньоры и безопасники. А, может, это станет твоим первым шагом, чтобы уйти в секьюрити ресёрч, стать киберэлитой и взламывать мир ему же на благо? 🎲 Каждый день — новый пост. Каждый пост — новая возможность стать круче. Подписывайся, включай уведомления и присоединяйся к игре. Мы взлетаем 🚀✨✨✨ #поиграемвКИ Ставь 👍, если ты с нами!

▶️ Записи Kaspersky Cyber Immunity Developers Night — открытой обучающей конференции по кибериммунной разработке — уже в доступе на нашем канале VK Video. 🟢видео №1 🟢Евгений Касперский. Приветственное слово 🟢видео №2 🟢Сергей Рогачев. Язык мой — враг мой? Безопасные и небезопасные языки программирования 🟢видео №3🟢Ольга Алёшина. Как применять GPU при разработке современных графических интерфейсов 🟢видео №4🟢Юрий Шведов. Удаленно управляем и отлаживаем С++ API с помощью KDS бесплатно, без регистрации и SMS 🟢видео №5🟢Андрей Наенко. Как маленькие ошибки могут оборачиваться большими уязвимостями 🟢видео №6🟢Татьяна Голубева, Олег Кировский. Совместим ли кибериммунитет с отраслевыми требованиями? 🟢видео №7🟢Андрей Карабань. Кибериммунитет и KasperskyOS в ООН: поддержка UN R № 155 🟢видео №8🟢Тимур Шарафеев. KASG: возможно ли сделать продуктовые сценарии быстрыми и безопасными 🟢видео №9🟢Валерий Овчинников. Как мы кибериммунный IoT-контроллер на KasperskyOS SDK разрабатывали 🟢видео №10🟢Александр Лифанов. Движение к продуктам с кибериммунитетом, или как учиться кибериммунной разработке 🟢видео №11🟢Ответы на вопросы о кибериммунной разработке и KasperskyOS Смотрите, комментируйте, переходите на нашу сторону кибериммунитета 👨‍💻

💡25 апреля в Екатеринбурге пройдет DUMP 2025 — главная IT-конференция Урала. Планируете участвовать? Обязательно приходите на стенд «Лаборатории Касперского»! 🤗 Покажем, как информационная безопасность работает на практике — без лишней теории и с элементами гейминга: ➡️CE: Построй безопасный WebServer — интерактивный опыт по созданию устойчивого веб-приложения; ➡️KasperskyOS CE Box — возможность бросить вызов нашей микроядерной операционной системе. Сумевшие открыть замок на базе KasperskyOS, получат приз. ➡️TONK: Турнир по игре Quake — культовая игра, запущенная на тонком клиенте TONK с KasperskyOS — чтобы уязвимостям точно не было шансов. А еще в программе — два доклада от наших экспертов: 🟢 «Хорошие, плохие и злые модели угроз в безопасной разработке». Екатерина Рудина, руководитель группы аналитиков по информационной безопасности «Лаборатории Касперского», расскажет, что делает модель угроз действительно полезной, и как её адаптировать под реальные задачи — без пустых формальностей и с пользой для бизнеса и разработчика. 🟢«Подходы к обеспечению информационной безопасности на практике». Алексей Цилябин, разработчик группы разработки KasperskyOS, разберет подходы, которые можно внедрять уже сегодня, от авторизации в критических системах до универсальных паттернов безопасности. В общем, приходите! 😎 Это отличная возможность не только оценить элегантность и надежность кибериммунных решений на базе KasperskyOS на реальных прототипах, но и задать нам вопросы о технологиях и возможностях нашей операционной системы. 🗓 Ждем вас 25 апреля в Екатеринбург-Экспо Конгресс-Центр на главной IT-конференции Урала.

😎 Пройди стажировку в «Лаборатории Касперского»! https://safeboard.kaspersky.ru 17 позиций в IT и ИБ ждут своих соискателей. ➡️Проверь собственные возможности. ➡️Покажи, из чего ты состоишь. ➡️Выбери то, что станет новой частью себя. Участвовать в отборе могут все, кто: 🟢Проживает в Москве либо Московской области. 🟢Является текущим студентом ВУЗа или Школы 21 и выпускается не раньше 2026 года. 🟢Готов уделять работе хотя бы 20 часов в неделю. Вуз и специальность не имеют значения — прежде всего, мы оцениваем кандидатов по итогам прохождения онлайн-тестов. Подробнее 👉 https://safeboard.kaspersky.ru Крайний срок подачи заявки — 20 апреля.

✔️ Новая роль моделирования угроз в процессе разработки Известно, что моделирование угроз (процесс поиска потенциальных угроз для системы) и разработка мер для защиты от этих угроз — процесс итеративный и дорогой. Но его можно значительно удешевить. Для этого посмотрим на задачу как изобретатель. В теории решения изобретательских задач (ТРИЗ) есть такой метод — «инверсия», когда для решения сложной задачи пробуют выполнить что-то наоборот. Например, изменить устоявшийся порядок операций (делать в начале то, что раньше делали в конце), радикально поменять ориентацию объекта (повернуть ось ветряка на 90°) или заменить действие на противоположное (отключать то, что раньше подключали). По аналогии с этим методом можно ли попробовать перевернуть смысл моделирования угроз с ног на голову? Использовать его не как инструмент поиска возможных угроз для системы, а как инструмент верификации — чтобы подтвердить, что все угрозы уже и так «закрыты». При этом мы начинаем рассматривать безопасность не как надстройку, а как неотъемлемую часть дизайна системы. Именно так подходят к работе в рамках концепции Secure by Design. Итак, как этот подход работает на практике: 1️⃣В самом начале нужно в явном виде описать объективные ценности продукта и те потенциальные неприятности, которые могут с ними случиться и которые для нас неприемлемы, — на уровне бизнес-назначения этого продукта. Иными словами, ответить на вопрос: «А что мы защищаем и от чего?» 2️⃣Понимая, что и от чего мы защищаем, определить цели безопасности: какие свойства системы должны сохраняться при любых обстоятельствах. (Больше о целях безопасности читайте здесь. 3️⃣Разработать такой дизайн решения, который гарантировал бы достижение поставленных целей безопасности. Сюда относятся: проектирование архитектуры, выбор протоколов, формулирование требований к структурированию и типизации данных и прочие аспекты проектирования. 4️⃣Уже на основе готового проекта, включающего в себя архитектуру решения, провести моделирование угроз. И если мы добросовестно отнеслись к предыдущим этапам, то моделирование должно подтвердить, что все угрозы, которые влияют на достижение целей безопасности, уже «закрыты». А тем угрозам, которые на цели безопасности не влияют, — мы и внимания много уделять не будем, ведь они не критичны. Возможно, на этом этапе мы выявим какие-то упущения, но вряд ли они потребуют пересмотра архитектуры. При моделировании угроз не для поиска, а для верификации мы перестаем решать задачу «что делать?», а переходим к решению более «дешевой» — «ничего ли мы не забыли?». В результате проектирование ответов на угрозы становится значительно дешевле. Кроме того, нам не потребуется повторно проводить моделирование угроз для обновленной с учетом прошлых «ошибок» архитектуры — а это дорогого стоит. Именно так выглядит кибериммунный подход к разработке. Эта на первый взгляд несложная рокировка на самом деле ломает устоявшиеся парадигмы и позволяет не только снизить затраты на разработку и поддержку системы, но и повысить уровень доверия к ней. Ставь 👍, если ты уже используешь подобный подход в процессе разработки.

Для проблем, связанных с существующими подходами к кибербезопасности, идеология Secure by Design предлагает простое и элегантное концептуальное решение. Оно звучит так: кибербезопасность должна быть не дополнительной деталью или нефункциональным требованием (вроде удобства использования, оно же usability, которое, очевидно, не приоритетно для разработчиков), а неотъемлемым свойством системы. При этом идеология Security by Design и ее описания в различных документах напоминают известный анекдот про зайцев, ежиков и мудрую сову.

Жили-были в лесу зайцы, и их все обижали. Как-то пошли они к мудрой сове за советом. Сова подумала и говорит: «А вы станьте ежиками Secure by Design, вас никто и обижать не будет». Зайцам совет понравился. «Но… как же нам стать ежиками Secure by Design?» — спросили они. «Вы меня ерундой не грузите, я стратегией занимаюсь, а тактика — это не ко мне», — ответила сова.

Другими словами, идеология Security by Design сама по себе не предлагает никаких инструкций, которым нужно следовать для реализации такой «врожденной» защиты. Конкретику привносит именно кибериммунитет: 🟢Конкретная методология: как именно организовать процесс разработки и какие результаты необходимы на каждом этапе. 🟢Требования к дизайну: как именно должна быть спроектирована система, чтобы реализовать подход Security by Design экономически эффективным способом. ☝️Идеологию Security by Design стоит воспринимать как фундаментальную основу, а кибериммунитет — как конкретный набор методов и инструментов, превращающих эту концепцию в прикладную реальность. Внедрение кибериммунитета требует донастройки процессов разработки, но результат оправдывает усилия.

Вспомните, как бурлил интернет, обсуждая микроархитектурные уязвимости вроде Meltdown и Spectre, найденные практически во всех современных процессорах! Это было что-то совершенно новое, потребовавшее аппаратных и программных митигаций на самом низком уровне. Мир не стоит на месте: развиваются не только средства защиты, но и механики взломов. 🫣 И в будущем злоумышленники будут использовать технологии и подходы, которые сегодня нам пока не известны. А потому уже на стадии разработки необходимо принимать меры, которые помогут снизить вероятность успеха этих будущих атак, а то и полностью свести к нулю все усилия взломщиков. О предпосылках создания кибериммунного подхода и заложенных в него механизмах, а также о тонкостях разработки и внедрения конструктивно безопасных решений наша новая статья в «Кибериммунном блоге».

На вебинаре «Обновления в Kaspersky Thin Client 2.3: Новые сценарии и возможности», который прошел 27 февраля 2025 года, эксперты «Лаборатории Касперского» Семён Мазуров, Михаил Левинский и Александр Федорченко продемонстрировали новинки кибериммунного тонкого клиента и показали его работу в деле. А ещё — поделились кейсами успешных внедрений! Смотреть вебинар можно на одной из наших площадок: ➡️YT — https://kas.pr/hr6x ➡️RT — https://kas.pr/nc7q ➡️VK — https://kas.pr/py1x Мы обсудили: 🟢Новые функциональные возможности Kaspersky Thin Client 2.3 🟢Приложения, расширяющие возможности для сотрудников: от мультимедиа, до новых типов подключений к удаленным рабочим столам 🟢Средства централизованного управления парком устройств 🟢Передовой подход к киберзащите рабочего места сотрудника 🟢Новые инструменты для администратора: полный контроль над отдельными устройствами и над всей инфраструктурой 🟢Реализованные проекты и результаты внедрения Не пропусти следующее мероприятие! 🔥 Узнать подробнее о решении и задать вопрос можно по ссылке: kas.pr/23vm 00:01 - 01:39 - Вступление 01:39 - 25:21 - Новые функциональные возможности Kaspersky Thin Client 2.3 25:21 - 42:45 - Демонстрация продукта 42:45 - 43:55 - Как попробовать? 43:55 - 46:20 - Реализованные проекты и результаты внедрения 46:25- 47:20 - ТСО 47:21 - 48:30 - Награды и достижения 00:48:30 - 01:02:41 - Ответы на вопросы 01:02:42 - 01:06:34 - Песня #KasperskyThinClient #KasperskyOS #KTC #Тонкийклиент #кибериммунитет