Проблемы безопасности современных киберсистем
Для современных киберсистем характерно взаимопроникновение информационных (ИT) и операционных (ОТ) технологий. Конвергенция ОТ и ИT изменила само понятие безопасности. Ранее киберсистемы использовались для обработки данных и под безопасностью понимались аспекты их целостности, конфиденциальности и доступности. Сегодня важность также приобретают функциональная безопасность, устойчивость, надежность работы и другие аспекты безопасности системы, определяемые обработкой данных.
Разработка безопасных киберсистем и их поддержка сопряжены с рядом сложностей, включая:
- отсутствие единого понимания целей деятельности: заказчики не могут описать критерии безопасной системы, а разработчики внедряют меры безопасности без понимания их необходимости и достаточности;
- высокую сложность и стоимость доказательства свойств безопасности;
- высокие затраты на квалифицированных сотрудников, особенно специалистов на стыке отраслевых дисциплин и кибербезопасности.
При разработке программных или программно-аппаратных продуктов вопрос безопасности возникает ближе к концу проекта, поскольку требования безопасности традиционно рассматриваются как нефункциональные. В этом случае защитные меры, реализованные в отрыве от основного функционала продукта, нередко оставляют лазейки для злоумышленника и не позволяют эффективно противостоять атакам.
Кибериммунный подход к разработке киберсистем
Кибериммунный подход — это эволюционное развитие технологий обеспечения безопасности, основу которого составляют теоретическая база и мировые практики построения безопасных систем в области промышленности, транспорта, управления. Подход объединяет экономически эффективную методологию разработки киберсистем с архитектурными требованиями к ним, что позволяет применять его в различных сферах.
Целью кибериммунного подхода является создание кибериммунной системы — киберсистемы, декларированные активы которой защищены от нежелательных событий при любых условиях, даже под атакой, при условии заданных ограничений.
Кибериммунный подход состоит из двух частей.
- Требования к организации разработки (процессные требования). Они определяют, какие действия необходимо и достаточно предпринять и какие результаты получить, чтобы обеспечить экономически эффективную разработку безопасной архитектуры;
- Требования к архитектуре и дизайну системы. Это базовые концепции, которые должны быть заложены в архитектуру и дизайн, чтобы обеспечить высокий уровень безопасности системы и высокий уровень уверенности в ее безопасности.
Процессные требования кибериммунного подхода
Кибериммунный процесс предъявляет требования к результатам каждого этапа разработки, но не регламентирует жестко, как именно выполняется работа, ограничиваясь методическими рекомендациями.
Цели безопасности
Определение целей безопасности — первый этап разработки кибериммунной системы.
Цели безопасности могут определяться разными методами: для отраслей с высоким уровнем регуляции — путем анализа требований регулятора, для сфер, где регуляция практически отсутствует, — на основе анализа потребностей в безопасности, определенных владельцем или заказчиком. Эти потребности часто связаны с защитой активов системы, и на практике заказчику понятно, как формулировать задачи по безопасности, отталкиваясь от них. Таким образом, кибериммунный подход применим ко всем прикладным сферам разработки киберсистем.
Важный практический аспект подхода — противостояние «перекладыванию ответственности». Любые технические средства, технологии и инструментарий защиты, например криптографические ключи, пароли, сертификаты и др., не рассматриваются как актив системы и не должны фигурировать в поле зрения заказчика. С одной стороны, это дает возможность заказчику самому определять активы системы на своем языке, не перекладывая эту задачу на разработчика, с другой — не сужает задачу и не ограничивает разработчика в выборе средств и методов защиты.
Перед разработкой архитектуры под заданные цели безопасности каждая цель конвертируется в набор требований безопасности, которые детально описывают, что именно надо сделать, чтобы обеспечить достижение этой цели, т. е. формируются требования к функциям защиты. На данном этапе и появляются требования вроде обеспечения защиты криптографических ключей.
Моделирование угроз
Моделирование угроз активно используется в методологии создания кибериммунных систем. Чтобы этот инструмент был эффективен, важно понимать, к какому объекту применять моделирование, какие исходные данные и методы использовать, какие результаты нужно получить.
- Техническое моделирование. Чаще всего под термином «моделирование угроз» понимают технические процедуры, которые опираются на базы знаний о типовых угрозах, векторах, техниках и тактиках кибератак (MITRE, STRIDE, БДУ ФСТЭК). Обязательный результат — артефакт под названием «модель угроз», который описывает источники угроз или модель нарушителя, перечень исходящих угроз, актуальные технические сценарии реализации.
- Верхнеуровневое моделирование. Верхнеуровневое моделирование угроз — менее формальная процедура, для которой необязательно иметь полностью описанную архитектуру системы. Такой тип моделирования угроз можно назвать «а что будет, если…».
Кибериммунный подход использует оба типа моделирования угроз: верхнеуровневое — для создания архитектуры под заданные цели безопасности, формальное техническое — для проверки качества разработанной архитектуры, исправления ошибок или подтверждения того, что архитектура соответствует целям безопасности.
Создание архитектуры под цели безопасности
Еще до формального моделирования угроз необходимо определить критические части системы, непосредственно отвечающие за активы, и изолировать их от любого возможного нежелательного воздействия.
Для этого следует контролировать взаимодействия критических частей системы со всеми остальными, делить их на более мелкие и оставлять среди критических только самое необходимое. Данный процесс выполняется на всем протяжении формирования базовой архитектуры системы.
Мы постоянно отвечаем на вопрос: «Что, если тот или иной компонент будет скомпрометирован?». В результате остается относительно небольшое число критических компонентов, которые не должны быть скомпрометированы. Их необходимо очень тщательно разработать, протестировать и верифицировать. Поверхность атаки на эти компоненты, следовательно на всю систему, будет мала, а стоимость атаки — высока.
Такой подход не отрицает проведение полноценного технического моделирования угроз. Но позволяет уменьшить объем изменений архитектуры после технического моделирования, в идеальном случае — до нуля. Кроме того, подобный подход обеспечивает более высокую устойчивость системы к угрозам, сценариям и способам атак, которые не были известны на момент моделирования угроз.
Верификация качества кода
Особенность кибериммунного подхода заключается в том, что строгой верификации подвергается не весь код, а сравнительно небольшая его часть — только так называемый доверенный код, критические компоненты, непосредственно влияющие на достижение целей безопасности. Остальной код верифицируется наиболее экономичными способами.
Требования к архитектуре и дизайну кибериммунной системы
Базовых требований к архитектуре и дизайну системы несколько:
- строгая изоляция компонентов друг от друга, исключающая их неконтролируемое взаимодействие;
- обязательный контроль разрешенных коммуникаций между изолированными компонентами на основе формализованных политик безопасности;
- выделение подмножества доверенного кода из всего множества кода системы (TCB, trusted computing base) и минимизация этого подмножества;
- соответствие схемы разрешенных коммуникаций между доверенными и недоверенными компонентами кибериммунной модели целостности, о которой мы поговорим далее.
Изоляция и контроль
Базовые архитектурные паттерны, которым предлагает следовать кибериммунный подход, представлены в архитектурной концепции MILS и архитектуре FLASK и основаны на системе с разделением доменов. Это система, разделенная на строго изолированные модули, называемые доменами безопасности, коммуникации между которыми определяются архитектурой политики и контролируются ядром разделения системы. Все остальные функции безопасности реализуются внутри изолированных доменов безопасности.
Преимущество подхода в том, что в системе с разделением доменов можно сделать доказательные выводы об уровне защищенности всей системы в целом за конечное время. В тех случаях, когда система нетривиальна и состоит из гетерогенных компонентов, разработанных, возможно, разными поставщиками, это свойство становится не просто желательным, а необходимым.
Кибериммунная модель целостности
Одно из центральных понятий системы с разделением доменов — архитектура политики, т. е. схема допустимых направленных взаимодействий между изолированными компонентами системы.
Кибериммунный подход предъявляет дополнительное требование: система связей, заданная архитектурой политики, должна отвечать кибериммунной модели целостности, которая является модификацией модели целостности Биба и по смыслу близка модели целостности Кларка — Вилсона.
Для этого все домены безопасности разделяются на три класса: недоверенные, доверенные и те, которые повышают доверие к проходящим через них данным. Классифицируются они на основании влияния на достижение заданных целей безопасности (напомним, что задача кибериммунной системы — обеспечить достижение этих целей при любых обстоятельствах).
Кибериммунная модель целостности отличается от модели Биба (как и модель Кларка — Вилсона) наличием дополнительного класса с доверенными системными компонентами, такими как ядро разделения и монитор безопасности.
Кибериммунный подход подчеркивает важность доказательства надежности программного кода. Однако доказывать надежность каждого компонента системы чрезвычайно дорого и не всегда возможно как из-за огромного объема кода, так и из-за использования заимствованного кода, который может часто обновляться.
Если системные компоненты верифицируются поставщиком, то верификация прикладных доверенных компонентов — обязанность прикладного разработчика. Поэтому код прикладных доверенных компонентов должен быть минимизирован, иначе верификация займет слишком много времени или будет коммерчески нецелесообразной.
Недоверенные компоненты также верифицируются, но наиболее простыми и малозатратными методами. К доверенным компонентам предъявляются определенные требования: они должны быть функционально просты, иметь небольшое количество интерфейсов со строгой типизацией элементов, повышающих целостность. Его необходимость обоснована практикой: одновременно соблюсти модель целостности Биба и реализовать весь необходимый прикладной функционал — не всегда решаемая задача. От модели Кларка — Вилсона кибериммунная модель целостности отличается меньшим объемом требований, также исходя из практических соображений.
Что касается конфиденциальности и других аспектов безопасности, то контроль функциональной целостности и целостности данных — необходимые условия обеспечения любых других видов безопасности. Поэтому поддержание целостности функций и данных на системном уровне — необходимое условие, тогда обеспечение остальных аспектов безопасности возможно на прикладном или промежуточном уровне.
Доверенный и недоверенный код, минимизация TCB
Все модули кибериммунной системы классифицируются как недоверенные, доверенные и повышающие уровень доверия к данным. Модули системы, относящиеся к двум последним классам, входят в TCB наряду параметров, быть небольшими по объему кода и функционально однородными. Эти требования направлены на минимизацию поверхности атаки на доверенные компоненты, а также на оптимизацию затрат на верификацию.
Подобно концепции Zero Trust, кибериммунная система сводит контроль поверхности атаки на систему к контролю относительно небольшой поверхности защиты, образованной доверенными компонентами. Гарантировать качество поверхности защиты технически проще, за счет чего киберсистема будет более надежной с точки зрения безопасности.
Более подробно ознакомиться с концепцией кибериммунитета и узнать, что надо делать, чтобы защитить свой бизнес, можно по ссылке.
