Мы уже рассказывали о студенческой олимпиаде по информационной безопасности РГУ, где одна из ключевых задач звучала так: «Разработайте умный 🚦светофор, который даже в случае хакерской атаки не допустит опасных сочетаний сигналов, способных спровоцировать ДТП».

Команды получали незащищенный функциональный код, управляющий всеми компонентами светофора и, в том числе, цветными светодиодными панелями. Задачей участников было внедрить механизмы кибериммунитета:
🟣выделить доверенную зону,
🟡обособить критические модули
🟢и обеспечить, чтобы внутренние или внешние атаки не смогли нарушить логику безопасного переключения сигналов.

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

Однако, один из самых запоминающихся и забавных эпизодов оказался вовсе не про кибербезопасность, а про… незнание Правил дорожного движения 🙈.

Оказалось, что студенты, сконцентрировавшись на борьбе с хакерами, как-то упустили факт, что светофор должен меняться по чётким регламентам ПДД. В результате на одном из стендов «идеально работающий» код разрешал одновременно зелёный для встречных потоков или включал жёлтый и зелёный одновременно для одной полосы. Словом, комбинации, которых в ПДД не бывает и которые могут привести к беде. Ирония в том, что основные «баги» лежали вовсе не в алгоритмах шифрования или проверках целостности, а в банальном незнании или неверном толковании правил дорожного движения.

Похоже, в борьбе с киберугрозами не стоит забывать и о базовой теории! 😉

27 июня на площадке Пермского государственного национального исследовательского университета (ПГНИУ) прошла тематическая конференция по кибербезопасности, где выступил Юрий Шишкин, менеджер образовательных программ «Лаборатории Касперского», с докладом «Просто о сложном».
👉 Презентация доклада

Темы, которые обсудили участники:
🟢Кибериммунитет как методология, которая не просто «латает дыры», а сохраняет целостность системы даже при их обнаружении новых уязвимостей.
🟢Три кита кибериммунного подхода: изоляция компонентов, строгий контроль взаимодействий и минимизация доверенной кодовой базы.
🟢Почему «просто зашифровать трафик» или «написать всё с нуля» ≠ «сделать безопасно».
🟢Как смена парадигмы с «как закрыть абсолютно все уязвимости» на «как построить надежное решение из ненадёжных в массе своей компонентов» переворачивает привычные процессы разработки.
🟢Опыт Кaspersky OS как удобной операционной системы при реализации кибериммунного подхода.

«Кибериммунитет — крутая концепция, которая в вечной дуэли хорошего разработчика и плохого хакера даёт разработчику шанс вырваться вперёд», — утверждает Юрий Шишкин.

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

‼️Формулировка целей безопасности (ЦБ) для многих по-прежнему является сложной задачей.

В поиске решения этой проблемы, мы создали телеграмм-бот @CyberGoalBot, который
1️⃣➖Принимает список целей / предположений безопасности одним сообщением.
2️⃣➖Проводит автоматический анализ качества предложенной ЦБ:
— выявляет соответствие методологическим критериям,
— указывает противоречия и неясности,
— формирует рекомендации по улучшению формулировок.

Кому это может быть полезно?
Каждому, кто изучает, обучает или практикует кибериммунную разработку 😎.

Попробуйте сами и напишите нам о своем опыте. Насколько @CyberGoalBot оказался эффективен? Есть ли в нем что-то, что стоит улучшить или добавить?

Совсем недавно мы рассказывали о боте @CyberGoalBot, умеющем проверять корректность постановки целей безопасности. И задумались: а хорошо ли наши подписчики понимают разницу между целями и предположениями безопасности?

Давайте сравним эти два понятия.

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

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

И, например, такие предположения безопасности:
🟢У злоумышленника отсутствует физический доступ к устройству.
🟢Появление внутреннего нарушителя маловероятно.

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

Так цели и предположения безопасности ложатся в основу последующей разработки требований к системе.

Проверяй и НЕ доверяй 👻

Последние дни все новостные порталы только и говорят что об успешных хакерских атаках на IT инфраструктуру (Аэрофлот, сети аптек). Полученный ущерб пока трудно оценить, но бизнес определённо пострадал.

Детальный анализ действий хакеров, будем надеяться, еще будет опубликован для изучения и извлечения уроков. 

Однако, по обрывкам информации в прессе уже можно сделать первые выводы:
1️⃣в работе компаний по-прежнему делается фокус на защите внешнего периметра;
2️⃣неоправданно высокий уровень доверия многочисленным внутренним ИТ системам;
3️⃣неявно делается предположение безопасности (ПБ) о благонадёжности и достаточном уровне квалификации сотрудников, имеющих доступ к критическим системам и способных причинить им ущерб путём компрометации данных, изменения настроек.
При этом такое ПБ не контролируется должным образом: возможно, эта функция не закреплена за ответственными структурами в компании или у этих структур не хватает квалификации / ресурсов для воплощения всех требуемых мероприятий.

В прочем, о чем это мы?
Так как всегда: о кибериммунном подходе! 🤗

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

Т.е. в любой ситуации необходимо исходить из неблагонадёжности максимального количества технических компонентов и сотрудников, а всё то, что является критическим для целей безопасности, — должно быть реализовано и проверено дважды. Или трижды.

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

Товарищи, внедряйте идеи кибериммунной разработки / конструктивной информационной безопасности, пока это не стало слишком поздно для вашего бизнеса!
🤝

💚💚💚💚1️⃣💚
Моделирование угроз в кибериммунном подходе

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

Однако, спроектировать с нуля такую устойчивую к атакам систему — задача не из легких. Для этого нужен особый подход к разработке — Secure by Design — когда безопасность продумывается и закладывается в систему уже на первых шагах разработки.

И одним из ключевых инструментов кибериммунного подхода является моделирование угроз.

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

Моделирование угроз развивается из общего понимания бизнес-целей системы и приоритетов заказчика: на этом этапе уточняют, какие именно свойства наиболее критичны, при каких условиях будет работать устройство, какие типы атак наиболее вероятны и каков потенциальный ущерб. Итогом становится набор негативных сценариев, который позже ляжет в основу политики архитектуры.

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

В классическом варианте при моделированием угроз ограничиваются техническим моделированием, однако в кибериммунном подходе выделяются две разновидности этого процесса, решающие разные задачи, но при этом дополняющие друг друга:
🟢Техническое моделирование угроз. Подразумевает формальные процедуры анализа угроз на основе известных баз знаний о типовых уязвимостях и атаках (например, методики STRIDE, базы данных MITRE ATT&CK, БДУ ФСТЭК и др.).
Техническое моделирование максимально приближено к реальным векторам атак, но требует много времени и данных об архитектуре.

🟢Верхнеуровневое моделирование угроз. Менее формальный подход, который можно начать на ранних стадиях проектирования, не дожидаясь детальной проработки архитектуры. Фактически, это серия мысленных экспериментов в формате «а что будет, если…». Разработчики и аналитики перебирают различные гипотетические ситуации компрометации каждого из внутренних компонентов, выявляя сценарии, приводящие к нарушению целей безопасности.
Верхнеуровневое моделирование позволяет подсветить архитектурные уязвимости и требования к защите ещё до фактической реализации системы. Например, на этом этапе задаются вопросы: «Что если злоумышленник получит доступ к модулю X?», «Какие последствия это повлечёт?» Такие обсуждения не требуют точной спецификации системы — они опираются на общее видение компонентов и взаимодействий.

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

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

💚💚💚💚2️⃣💚(а скорее даже Тема «ноль»)
Цели и предположения безопасности как основа конструктивно-безопасной разработки

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

Для этого на самом старте формируется концепция безопасности продукта: задаются цели безопасности и формулируются предположения безопасности о том, в каких условиях будет эксплуатироваться система.

➡️Цели безопасности (ЦБ) описывают требуемые свойства системы, которые должны сохраняться во всех сценариях ее работы. Иначе говоря, это глобальные требования к безопасности системы в целом, выполнение которых гарантирует защиту ключевых активов заказчика и не допускает неприемлемые риски. Например, целью безопасности может быть условие «при чтении, записи и передаче данных эти данные остаются неизвестными для неавторизованных лиц».

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

➡️Предположения безопасности (ПБ) — это условия и ограничения эксплуатации, при которых должны достигаться цели безопасности. Иными словами, они задают границы модели угроз: какие исходные условия считаются нормальными, а какие уходят за рамки области рассмотрения.

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

🔖 Пример
Для промышленного шлюза передачи данных ЦБ может формулироваться так: «обеспечить одностороннюю передачу данных во внешнее облако без возможности воздействия на внутреннюю сеть предприятия».
ПБ при этом могут включать требование, что физический доступ к шлюзу ограничен организационными мерами предприятия.

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

Определив цели и предположения безопасности, команда фактически создает образ защищаемой системы и рамки, внутри которых предстоит работать.

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