Skip to content

Кибериммунитет

Jump to bottom
Sergey Sobolev edited this page Mar 25, 2024 · 30 revisions

Кибериммунитет

Примечания

1. если какие-то термины на этой странице непонятны, посмотрите здесь

2. в некоторых диаграммах используется Archimate нотация, см. раздел Дополнительные материалы

3. Если у вас есть вопросы, предложения, пожелания - подписывайтесь на наш канал в Телеграм https://t.me/learning_cyberimmunity и напишите нам!

В качестве вступления

Мотивация для внедрения механизмов безопасности на всех этапах жизненного цикла информационных систем

CIMOTIV

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

Профильные компании фиксируют качественный рост числа атак и успешных взломов в 2022 году, в том числе увеличение целенаправленных атак (APT - advanced persistent threat), причём объектами атак становятся не только госструктуры и большие компании-операторы критической инфраструктуры, но и предприятия среднего и даже малого бизнеса.

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

В качестве реакции на выросшие риски появился указ Президента РФ от 01.05.2022 №250 "О дополнительных мерах по обеспечению информационной безопасности РФ", вводящий персональную ответственность за обеспечение информационной безопасности для руководства компаний.

Продолжает действовать федеральный закон №187 от 26.07.2017 "О безопасности критической информационной инфраструктуры РФ".

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

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

Кибериммунитет как ответ на растущие риски информационной безопасности

С практической точки зрения, кибериммунитет нацелен на решение следующих проблем:

  • смыкание разрыва проектирования безопасности (архитектура – кодинг – харденинг) через распараллеливание написания функционального кода и политик безопасности, причем политики могут быть протестированы без наличия самого кода;
  • обезопашивание использования недоверенных сторонних (например, open source) компонентов через контроль их входящих и исходящих коммуникаций;
  • решение конфликта непонимания между разработчиками функционального кода и архитекторами безопасности через использование унифицированной нотации интерфейсов, коммуникаций, политик (Security as a Code);
  • с точки зрения менеджмента разработки ПО – удешевление и ускорение цикла разработки за счет исключения циклов возврата и переработки, плюс того же распараллеливания работы
  • с точки зрения аттестанта и эксплуатанта систем – появление дополнительных документальных артефактов, подтверждающих идеи, заложенные в архитектуру системы, возможность тестирования необходимых (как заранее запроектированных, так и не запроектированных) негативных сценариев воздействия на оригинальный код

Кибериммунитет подразумевает внедрение механизмов защиты на этапе проектирования, для полноценной работы этих механизмов нужна поддержка на системном (а в некоторых случаях и на аппаратном) уровне, поэтому внедрение данного подхода является частным случаем применения конструктивных (встроенных) средств защиты, которые рекомендуются в п. 27 приказа №239 ФСТЭК:

"27. Технические меры по обеспечению безопасности в значимом объекте реализуются посредством использования программных и программно-аппаратных средств, применяемых для обеспечения безопасности значимых объектов – средств защиты информации (в том числе встроенных в общесистемное, прикладное программное обеспечение), а также обеспечения безопасности программного обеспечения и программно-аппаратных средств, применяемых в значимых объектах.

При этом в приоритетном порядке подлежат применению средства защиты информации, встроенные в программное обеспечение и (или) программно-аппаратные средства значимых объектов (при их наличии)."

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

Артефакты, методы и шаблоны кибериммунной разработки

1. Концепция безопасности продукта.

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

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

Видео с более подробной информацией о документе можно посмотреть по ссылке.

2. Цели и предположения безопасности

Следующим шагом после анализа этого документ является выработка целей и предположений безопасности (ЦПБ)

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

Под безопасностью в данном контексте, как правило, понимается security (информационная безопасность - ИБ), а не safety (функциональная безопасность - ФБ). В некоторых сценариях угрозы ИБ могут приводить к угрозам ФБ.

ЦПБ в идеале вырабатываются совместно

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

SGA

Видео с объяснением ЦПБ, критериями оценки качества можно посмотреть по ссылке.

2. Анализ угроз

Моделирование, анализ и оценка угроз может проводиться в соответствие с методикой ФСТЭК. Результатом этой работы будет список угроз и сценарии их реализации

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

Негативные сценарии

Наглядный и достаточно удобный способ описания негативного сценария - диаграмма последовательности вызовов (sequence diagram), финалом которых является получаемый ущерб (или нарушение цели безопасности). Сами диаграммы можно рисовать с помощью различных инструментов - как графических (MS Visio, Draw.io, Lucidcharts и т.п.), так и описывать как код, получая в результате автоматически сгенерированные диаграммы (см. Plantuml)

В качестве примера можно рассмотреть такую диаграмму: NSD

На диаграмме красным цветом выделена скомпрометированная сущность (Manager) и вредоносное действие (или в общем случае - действие, нарушающее одну или несколько целей безопасности) - обновление системы прошивкой без предварительной верификации. Более подробно эта и другие диаграммы рассматриваются в примере secure update

Последовательность описания негативного сценария

Рассмотрим диаграмму https://kas.pr/2eth и цель безопасности "Движение осуществляется только по авторизованным маршрутам"

  1. Выбираем отправную точку - источник атаки, в примере по ссылке - это "Навигация", красим этот компонент красным - добавляем #red к строке - в примере:participant "Навигация" as Navigation #red
  2. Показываем развитие атаки (начинаем со стрелки от Навигации красного цвета, см. шаг №4 - данные от Навигации к ЦСУ) в коде диаграммы это делается добавлением [#red] в стрелку: CentralControl <[#red]- Navigation: текущие координаты
  3. Последующие стрелки окрашиваем в красный, т.к. без дополнительных усилий вся дальнейшая работа системы основана на неправильных координатах, окрашиваем в красный целиком логические блоки, которые на диаграмме собраны в группы: group #red [2] Следование по маршруту к месту погрузки
  4. Заканчиваем состоянием, явно нарушающим одну или несколько целей безопасности. В сценарии с атакой через навигацию это, очевидно, нарушение цели безопасности (наш грузовик перемещается по неавторизованному маршруту).

Опционально можно красным показать нарушение целостности данных вплоть до передачи недостоверных данных во внешние системы.Зачем это: компоненты, атаки через которые нарушают цели безопасности (хотя бы одну), мы обязаны вводить в доверенную кодовую базу.

При этом задача архитектора - минимизация доверенной кодовой базы (TCB - trusted computing base), поэтому добавляет в TCB только те компоненты, которые, согласно анализу негативных сценариев, критичны. Или по-другому - негативные сценарии - это способ обоснования и документирования архитектурного решения по расширению TCB.

3. Декомпозиция системы

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

Decomposition

Домены безопасности

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

  • в микросервисных архитектурах каждый сервис, в идеале, отвечает за определённую (возможно, одну-единственную функцию), в больших системах таких микросервисов могут быть десятки и сотни. Например, может быть сервис хранения данных, его функция - получать / выдавать данные и осуществлять контроль их изменений. Другой пример - сервис аутентификации и авторизации.
  • в доменно-ориентированном подходе (domain driven design) каждый сервис отвечает за набор функций определённого функционального домена. Например, сервис оформления заказа в интернет-магазине или сервис оформления доставки. Внутри каждого такого сервиса (домена) может быть своя терминология и, как правило, отдельная команда, которая занимается реализацией этого сервиса.

Домены безопасности должны ориентироваться на принятую декомпозицию системы - как минимум, каждый (микро)сервис будет представлять из себя отдельный домен. Более того, каждый экземпляр (микро)сервиса также будет отдельным доменом.

Доверенные и недоверенные компоненты

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

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

Но это может быть комплексом мер, например:

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

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

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

4. Архитектурные диаграммы

Для задач проектирования кибериммунитета достаточно высокоуровневой архитектуры (high level architecture -HLA), описывающие сущности и связи между ними, но также могут быть полезны диаграммы развёртывания (deployment diagram), описывающие физическое размещение и среду выполнения подсистем.

4.1. Политика архитектуры

Политика архитектуры - это особый вид описания архитектуры системы с точки зрения разделения на домены безопасности и указания разрешённых направлений передачи данных.

ArchPol

Видео с объяснением этого типа диаграммы можно посмотреть по ссылке.

5. Политики безопасности

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

Политики безопасности вырабатываются на основе ЦПБ, анализа угроз и архитектуры системы. SecPol

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

Примеры описания политики безопасности:

  • используется PSL из инструментария KasperskyOS (см. ниже)
/**
 * This code enables to send requests from GPIO entity to KOS kernel
 * and get responses.
 */
request src = kl.drivers.GPIO, dst = kl.core.Core
{
    grant()
}

response src = kl.core.Core, dst = kl.drivers.GPIO
{
    grant()
}
  • используется Python из альтернативного инструментария на базе брокера (см. ниже)
    if  src == 'downloader' and dst == 'manager' \
        and operation == 'download_done':
        authorized = True    
    if src == 'manager' and dst == 'downloader' \
        and operation == 'download_file':
        authorized = True

Платформы и инструменты

KasperskyOS

Кибериммунитет в KasperskyOS основан на трех вещах:

  1. микроядерной архитектуре ОС
  2. межпроцессных коммуникациях на основе подхода MILS
  3. управлении политиками на основе FLASK

Микроядерная архитектура, положенная в основу KasperskyOS, реализует следующие преимущества. Прежде всего, это уменьшение размеров ядра ОС, уменьшающее поверхность атаки и упрощающее его формальную верификацию. Также, понижение уровня всех некритичных для функционирования процессов до пользовательского уровня упрощает контроль за их взаимодействиями.

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

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

Взаимодействие между процессами может осуществляться только после положительного решения специально для этого предназначенного модуля безопасности (Kaspersky Security Module, KSM), реализующего принцип единственного Policy Enforcement Point. Это решение выносится на основе формализованных политик, использующих специализированную нотацию с type enforcement (принцип FLASK).

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

Хотя Kaspersky OS - коммерческий продукт, существует бесплатная версия для обучения и прототипирования - Kaspersky OS Community Edition.

Как с ней работать можно узнать из короткого бесплатного курса на платформе stepik

Брокеры сообщений и контейнеризация

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

В таком случае каждая сущность может быть представлена в виде микросервиса, а взаимодействие между сервисами можно реализовать в виде асинхронной коммуникации (обмена сообщениями), которая будет контролироваться отдельным сервисом - монитором безопасности (МБ), а в качестве транспорта для безопасной и надёжной передачи сообщений может использоваться какой-либо из существующих на рынке брокеров (например RabbitMQ, Kafka, Mosquitto).

Выбор брокера сообщений зависит от требований защищённости, производительности, гибкости в настройке и масштабировании, уровне поддержки и других нефункциональных аспектов. С точки зрения архитектуры безопасности важно, чтобы все сообщения от отдельных микросервисов отправлялись сначала монитору безопасности, а только потом - конечному адресату. В такой ситуации МБ может заблокировать подозрительные сообщения и остановить распространение атаки вглубь системы.

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

Взаимодействие сервисов через брокера сообщений (при условии наличия библиотек взаимодействия с ним для выбранных технологических стеков) снимает большинство вопросов совместимости.

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

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

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

Учебные примеры использования кибериммунного подхода

Пример Описание Ссылка на репозиторий Платформа Язык программирования Комментарий
Secure update Безопасное обновление целевой системы * https://github.com/sergey-sobolev/secure-update - код
* https://github.com/sergey-sobolev/secure-update/blob/main/docs/report/report.md - описание		 брокер сообщений (Kafka) + docker Python Отчёт подготовлен как шаблон для описания итогов командной игры на хакатоне
Робот-доставщик Безопасная доставка груза получателю * https://github.com/Fishonground/delivery-robot/blob/main/report.md - описание
* https://github.com/Fishonground/delivery-robot - код		 брокер сообщений (Kafka) + docker Python Работа одного из участников внутреннего "пре-хакатона"
Робот-доставщик на Java Безопасная доставка груза получателю * https://github.com/BardinPetr/cyberimmune-delivery-robot/blob/main/docs/report.md - описание
* https://github.com/BardinPetr/cyberimmune-delivery-robot - код		 брокер сообщений (Kafka) + docker Java Работа одного из студентов
АСУ ТП для производства Контроль смешения химических веществ на производстве * https://github.com/Fishonground/chemical-ICS/blob/main/Report_v2.md - описание
* https://github.com/Fishonground/chemical-ICS - код		 брокер сообщений (Kafka) + docker Python Работа одного из участников внутреннего "пре-хакатона"
Дрон-опрыскиватель Обработка полей пестицидами с помощью дрона Описание

Приложения

Объединённая высокоуровневая диаграмма разработки кибериммунной системы

CIWF

Дополнительные материалы

  1. Основные определения
  2. Методика оценки угроз безопасности информации ФСТЭК
  3. Plantuml
  4. Курс по кибериммунной разработке с использованием Kaspersky OS
  5. Кибериммунитет в Kaspersky OS
  6. Краткий теоретический курс по информационной безопасности, включающий в себя основные концепции кибериммунитета
  7. Модели безопасности и архитектурные подходы к их реализации в системах критической инфраструктуры (доклад Екатерины Рудиной)
  8. Презентация об Archimate
  9. Описание мотивационных элементов в Archimate

Читайте и смотрите дальше

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

В образовательном процессе это можно представить в виде отдельного курса или раздела по информационной безопасности + secure by design, а в качестве заданий предложить студентам

Другие полезные ресурсы:

  • Курс на stepik, обучающий различным инструментам прототипирования, которые используются в учебных примерах: https://stepik.org/course/133991/info

  • Канал в youtube с записями занятий мини-курсов по кибериммунному подходу и другими обучающими видео https://www.youtube.com/@learning_cyberimmunity/playlists

  • Подписывайтесь на наш канал в телеграм для изучающих кибериммунный подход в разработке https://t.me/learning_cyberimmunity!

Clone this wiki locally