😎 Пройди стажировку в «Лаборатории Касперского»!
https://safeboard.kaspersky.ru

17 позиций в IT и ИБ ждут своих соискателей.
➡️Проверь собственные возможности.
➡️Покажи, из чего ты состоишь.
➡️Выбери то, что станет новой частью себя.

Участвовать в отборе могут все, кто:
🟢Проживает в Москве либо Московской области.
🟢Является текущим студентом ВУЗа или Школы 21 и выпускается не раньше 2026 года.
🟢Готов уделять работе хотя бы 20 часов в неделю.

Вуз и специальность не имеют значения — прежде всего, мы оцениваем кандидатов по итогам прохождения онлайн-тестов.
Подробнее 👉 https://safeboard.kaspersky.ru

Крайний срок подачи заявки — 20 апреля.

💡25 апреля в Екатеринбурге пройдет DUMP 2025 — главная IT-конференция Урала.

Планируете участвовать?
Обязательно приходите на стенд «Лаборатории Касперского»! 🤗

Покажем, как информационная безопасность работает на практике — без лишней теории и с элементами гейминга:
➡️CE: Построй безопасный WebServer — интерактивный опыт по созданию устойчивого веб-приложения;
➡️KasperskyOS CE Box — возможность бросить вызов нашей микроядерной операционной системе. Сумевшие открыть замок на базе KasperskyOS, получат приз.
➡️TONK: Турнир по игре Quake — культовая игра, запущенная на тонком клиенте TONK с KasperskyOS — чтобы уязвимостям точно не было шансов.

А еще в программе — два доклада от наших экспертов:
🟢 «Хорошие, плохие и злые модели угроз в безопасной разработке».
Екатерина Рудина, руководитель группы аналитиков по информационной безопасности «Лаборатории Касперского», расскажет, что делает модель угроз действительно полезной, и как её адаптировать под реальные задачи — без пустых формальностей и с пользой для бизнеса и разработчика.

🟢«Подходы к обеспечению информационной безопасности на практике».
Алексей Цилябин, разработчик группы разработки KasperskyOS, разберет подходы, которые можно внедрять уже сегодня, от авторизации в критических системах до универсальных паттернов безопасности.


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

🗓 Ждем вас 25 апреля в Екатеринбург-Экспо
Конгресс-Центр на главной IT-конференции Урала.

▶️ Записи 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

Смотрите, комментируйте, переходите на нашу сторону кибериммунитета 👨‍💻

Прод горит, а код еле держится «на костылях»?
Значит, это самое время выпить кофе переключиться и принять участие в игре, от которой зависит не только твой скилл, но и, возможно, будущая карьера!

Поиграем в кибериммунитет? 🙃
Ничего не понятно, но очень интересно!

📆 Стартуем в понедельник 28 апреля на нашем канале KasperskyOS. Разработка.

Что тебя ждёт во II Эпизоде?

▪️Реальные фейлы мирового масштаба: от British Airways до Tesla и Equifax. Разберём, почему это случилось, и как этого избежать в твоём коде.

▪️Кибериммунитет на пальцах: даже бабушкин петух умеет строить эшелонированную защиту лучше, чем специалисты многие компании. Поймёшь, почему.

▪️Жёсткие холивары и прикольные шутки с DevSecOps и безопасниками: узнаешь, почему чайнику не нужны рутовые права, и зачем думать, будто тебя уже взломали (спойлер: потому что, скорее всего, так и есть).

▪️Разделы «Вынос пользы для джуна» и «Пояснительная бригада», в которых всё, что нужно и важно, причем кратко и ёмко.


❓ Почему мы крайне рекомендуем потратить несколько минут в день на нашу игру.

Потому что твой код уже давно не только твоя задача. От него зависит как твоя зарплата, так и уважение команды, и твоя будущая карьера. Научишься применять кибериммунный подход к разработке — станешь человеком с которым реально советуются сеньоры и безопасники.

А, может, это станет твоим первым шагом, чтобы уйти в секьюрити ресёрч, стать киберэлитой и взламывать мир ему же на благо?


🎲 Каждый день — новый пост.
Каждый пост — новая возможность стать круче.


Подписывайся, включай уведомления и присоединяйся к игре.
Мы взлетаем 🚀✨✨✨

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

Ставь 👍, если ты с нами!

«Чтобы завоевать доверие, нужна вечность, для разочарования достаточно одного мига», — забавно, что эта фраза, напоминающая цитату из какой-нибудь 147-й серии бесконечной мыльной оперы, очень точно описывает важную проблему создания кибербезопасных систем.

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

Несмотря на всю зрелость методов, есть важная проблема: неясно, как грамотно и осознанно поделить код на тот, который надо проверять «задешево», и тот, который надо проверять «задорого». В результате для доказательства доверия к системе возникает потребность тщательно проверять чуть ли не весь ее код, что, конечно, почти невыполнимо на практике.

Решить эту проблему можно, следуя принципу минимизации доверенной кодовой базы. Смысл принципа в том, чтобы предельно уменьшить объем кода, критичного для безопасности системы. Тогда «дорогие» методы проверки нужно будет применить не для всего кода, а только для небольшой его части, тем самым значительно снизив затраты на анализ. Для остального же будет достаточно и базовых процедур.

На прикладном уровне принцип минимизации доверенной кодовой базы сводится к следующему:
🟢 как можно меньше доверенных компонентов должны непосредственно влиять на достижение целей безопасности системы;
🟢 сами доверенные компоненты должны быть достаточно простыми с точки зрения функциональности и иметь маленькую поверхность атаки.

На системном уровне:
🟢 должно быть как можно меньше кода, сосредоточенного в ядре безопасности операционной системы (оно состоит собственно из ядра ОС, монитора обращений и некоторых других модулей).

Именно этот принцип помогает разрабатывать кибериммунные системы.

1️⃣— Мир на костылях

Жара стояла такая, что даже серверная дышала с трудом. В командном чате горело:

«Критическая ошибка!», «Сломалось всё!», «Кто последний коммитил?!», «Бэкапы работают?», «Роллбек не помогает!»

Джун уставился в монитор, пытаясь глазами оживить графики мониторинга. Сердце колотилось: это его код ушёл в прод вчера ночью. Всё было нормально… Или нет?

Сеньор пил кофе и молча листал логи. Безопасник мрачно снимал скриншоты ошибок. DevOps вызывал древних богов Ansible. DevSecOps что-то шептал про «почему опять без авторизации?».

«Джун, дыши», — сказал себе наш герой, но сердце гремело, как перегруженный процессор.

— Но ведь тесты были зелёные! Всё работало! — наконец выдавил он вслух.

Сеньор лениво поднял бровь:
— На тестах оно и у бабушки работает. А в проде законы физики другие.

Джун сглотнул. В проде всё будто жило своей жизнью.

Безопасник оторвался от экрана:
— О, опять API платежей развалилось? Как неожиданно...

DevOps нервно хохотнул:
— Да, причём из-за фикса в комментариях.

— Это как? — переспросил Джун.

— Он как бабушкин дом — один угол чихнёт, второй осыпается. А что ты хочешь? Монолит...

В этот момент в офисе погас свет. Только серверная горела индикаторами, как маяк в ночи.

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

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

Джун моргнул. Он чувствовал, что сейчас узнает что-то важное.

— При чем тут кибериммунитет? Почему вдруг мы об этом заговорили?

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

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

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

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

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

▪️Минимизируй точки отказа. Если сервис не влияет на другой, его падение не должно нести критические последствия.

▪️Изолируй критичные зоны. Серверная в офисе выжила, потому что её заранее сделали отдельной. Код должен проектироваться так же.

▪️Думай, как защитить систему от самой себя. Иногда самый опасный враг продакшена — это код, который писали сами разработчики.

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

Монолит vs Микросервисы: монолитные системы часто страдают от эффекта «домино»: один сбой тянет за собой всю систему. В микросервисной архитектуре это частично решается, но без строгой изоляции проблемы всё равно распространяются.

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

Assume Failure: критические сервисы проектируются так, будто сбой неизбежен. Например, серверная на отдельной линии электропитания, как в примере.

Изоляция в коде: использование контейнеров (Docker, Kubernetes), политики доступа (RBAC, IAM), чёткое разграничение сервисов.

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

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

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): настройка прав доступа через ролевую модель — только необходимое.

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

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

📎 Мини-курс «Кибериммунитет за 3 вечера».

📆 СТАРТ — 10 июня в 19:00 по Мск.

✅Для истинных кодеров. Без сахара, ванили и хрупких систем.
✅Для тех, кто видит TODO в легаси-коде и понимает, что его никто не исправит.
✅Для тех, кто не просто пишет код, а понимает, что за ним стоит.

Присоединяйся к команде.
🔘https://vk.cc/cKFXlQ
Мы взлетаем 🚀✨✨✨

#поиграемвКИ
Ставь 👍, если ты с нами!

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.

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

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

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

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