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

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

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

Примечания

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

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

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

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

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

CIMOTIV

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

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

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

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

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

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

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

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

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

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

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

0. Цели и предположения безопасности (ЦПБ)

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

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

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

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

SGA

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

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

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

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

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

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

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

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

Decomposition

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это может выглядеть, например, так: DFD

На диаграмме

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

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

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

Политики безопасности вырабатываются на основе ЦПБ, анализе угроз и архитектуре системы. 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	Отчёт подготовлен как шаблон для описания итогов командной игры на хакатоне
Робот-доставщик	Безопасная доставка груза получателю	* https://github.com/Fishonground/delivery-robot/blob/main/report.md - описание * https://github.com/Fishonground/delivery-robot - код	брокер сообщений (Kafka) + docker	Работа одного из участников внутреннего “пре-хакатона”
АСУ ТП для производства	Контроль смешения химических веществ на производстве	* https://github.com/Fishonground/chemical-ICS/blob/main/Report_v2.md - описание * https://github.com/Fishonground/chemical-ICS - код	брокер сообщений (Kafka) + docker	Работа одного из участников внутреннего “пре-хакатона”
Дрон-опрыскиватель	Обработка полей пестицидами с помощью дрона	Описание

Приложения

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

CIWF

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

Читайте дальше

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

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

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