KasperskyOS

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: системы мониторинга поведения процессов и анализа логов помогают выявлять подозрительные активности.

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

Zero Trust в действии! #поиграемвКИ

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

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

Без проверки — без защиты. #поиграемвКИ Когда-то ты попал на наш канал, значит, тебе не всё равно, какой мир мы с тобой кодим. Ты знаешь, что код — это власть. Вопрос в том, насколько он устойчив к хаосу? Узнай на бесплатном мини-курсе «Кибериммунитет за 3 вечера», который стартует 1️⃣2️⃣. 0️⃣5️⃣. 👉 https://vk.cc/cKFXqU

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 Смотрите, комментируйте, переходите на нашу сторону кибериммунитета 👨‍💻