Продолжаем пополнять репозиторий VK Video. И сегодня в нашей ретроспективе видео с зимней конференции KOS Night 2022.

И в новом 👌 плейлисте:
🟢видео №1🟢Евгений Касперский. Вступительное слово
🟢видео №2🟢Сергей Рогачев. Глобальная жизнь кибериммунитета: почему кибериммунный подход уже захватил мир
🟢видео №3🟢Вячеслав Борилин. Нужно ли разработчику быть специалистом по ИБ?
🟢видео №4🟢Сергей Соболев. Кибериммунные ката: сложно ли их применять, если вы еще не пользуетесь KasperskyOS?
🟢видео №5🟢Игорь Подвойский, Владислав Фофанов. KasperskyOS в 3D: Development, Debugging, Drivers
🟢видео №6🟢Васил Дядов. «Святой Грааль» формальной верификации: достижения и планы
🟢видео №7🟢Вадим Ломовцев. Опыт разработки под KasperskyOS: портирование NodeJS
🟢видео №8🟢Александр Мотавин. KasperskyOS и Open Source: какие проекты и библиотеки доступны под KasperskyOS
🟢видео №9🟢Александр Лифанов. Планы KasperskyOS Community Edition: функциональность, документация, оборудование
🟢видео №10🟢Владимир Малыгин. Сообщество разработчиков под KasperskyOS: результаты 2022
🟢видео №11🟢Александр Лифанов. Я бы в кодеры пошел: где изучать разработку под KasperskyOS

▶️ Смотреть весь PlayList
Смотрите сами, делитесь с друзьями и коллегами 🧑🏻‍💻👩‍💻.

А наши эксперты всегда рады ответить на ваши вопросы в комментариях ниже.

На вебинаре «Обновления в 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 #Тонкийклиент #кибериммунитет

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

При этом идеология Security by Design и ее описания в различных документах напоминают известный анекдот про зайцев, ежиков и мудрую сову.

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

Другими словами, идеология Security by Design сама по себе не предлагает никаких инструкций, которым нужно следовать для реализации такой «врожденной» защиты.

Конкретику привносит именно кибериммунитет:
🟢Конкретная методология: как именно организовать процесс разработки и какие результаты необходимы на каждом этапе.
🟢Требования к дизайну: как именно должна быть спроектирована система, чтобы реализовать подход Security by Design экономически эффективным способом.

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

✔️ Новая роль моделирования угроз в процессе разработки

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

Для этого посмотрим на задачу как изобретатель. В теории решения изобретательских задач (ТРИЗ) есть такой метод — «инверсия», когда для решения сложной задачи пробуют выполнить что-то наоборот. Например, изменить устоявшийся порядок операций (делать в начале то, что раньше делали в конце), радикально поменять ориентацию объекта (повернуть ось ветряка на 90°) или заменить действие на противоположное (отключать то, что раньше подключали).

По аналогии с этим методом можно ли попробовать перевернуть смысл моделирования угроз с ног на голову? Использовать его не как инструмент поиска возможных угроз для системы, а как инструмент верификации — чтобы подтвердить, что все угрозы уже и так «закрыты». При этом мы начинаем рассматривать безопасность не как надстройку, а как неотъемлемую часть дизайна системы. Именно так подходят к работе в рамках концепции Secure by Design.

Итак, как этот подход работает на практике:
1️⃣В самом начале нужно в явном виде описать объективные ценности продукта и те потенциальные неприятности, которые могут с ними случиться и которые для нас неприемлемы, — на уровне бизнес-назначения этого продукта. Иными словами, ответить на вопрос: «А что мы защищаем и от чего?»

2️⃣Понимая, что и от чего мы защищаем, определить цели безопасности: какие свойства системы должны сохраняться при любых обстоятельствах. (Больше о целях безопасности читайте здесь.

3️⃣Разработать такой дизайн решения, который гарантировал бы достижение поставленных целей безопасности. Сюда относятся: проектирование архитектуры, выбор протоколов, формулирование требований к структурированию и типизации данных и прочие аспекты проектирования.

4️⃣Уже на основе готового проекта, включающего в себя архитектуру решения, провести моделирование угроз. И если мы добросовестно отнеслись к предыдущим этапам, то моделирование должно подтвердить, что все угрозы, которые влияют на достижение целей безопасности, уже «закрыты». А тем угрозам, которые на цели безопасности не влияют, — мы и внимания много уделять не будем, ведь они не критичны. Возможно, на этом этапе мы выявим какие-то упущения, но вряд ли они потребуют пересмотра архитектуры.

При моделировании угроз не для поиска, а для верификации мы перестаем решать задачу «что делать?», а переходим к решению более «дешевой» — «ничего ли мы не забыли?». В результате проектирование ответов на угрозы становится значительно дешевле. Кроме того, нам не потребуется повторно проводить моделирование угроз для обновленной с учетом прошлых «ошибок» архитектуры — а это дорогого стоит.

Именно так выглядит кибериммунный подход к разработке. Эта на первый взгляд несложная рокировка на самом деле ломает устоявшиеся парадигмы и позволяет не только снизить затраты на разработку и поддержку системы, но и повысить уровень доверия к ней.

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

😎 Пройди стажировку в «Лаборатории Касперского»!
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.

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