Ключевые моменты лекции 1 /
Аспекты безопасности, свойства, -ilities
Однако какие аспекты мы можем оценивать, и самое главное, что именно предполагает оценка? Это не только известная триада CIA, в нее давно «не помещается» все многообразие аспектов, которые требуют от доверенной системы. В интерпретации Industrial IoT Consortium, доверие включает аспекты компьютерной безопасности, функциональной безопасности, надежности, устойчивости и приватности. Определения можно найти в публично доступных документах IIC. Раз, два, три
Интерпретировав эти понятия, мы понимаем, что это еще не предел для так называемых “-ilities” (свойств, условно относимых к качеству системы). Их катастрофически много. Предлагается следующий bullshit детектор: 1. Свойство должно быть доступно для интерпретации и моделирования с внятным объяснением того, что имеется в виду под этим свойством 2. Интерпретация должна проходить неформальную валидацию – все заинтересованные стороны должны понимать его одинаково 3. Должен существовать способ проверки или измерения свойства (верифицируемость свойства). Пример – демонстрация испытаний стула в IKEA.
Свойства также разделяются на два типа: свойство «формальной безопасности» (safety) - «можно показать, что при определенных условиях некоторое нежелательное событие не произойдет» и свойство «формальной живости» (liveness) - «можно показать, что при определенных условиях некоторое желательное событие обязательно произойдет». Тип свойства важен для определения того, является ли оно верифицируемым, и как его можно верифицировать (или нельзя). Из пятерки свойств IIC trustworthiness safety, security и reliability – это свойства «формальной безопасности», а resilience и privacy – свойства «формальной живости» (как минимум в том виде, в котором их определяют документы IIC, при другом определении это может поменяться).

Ключевые моменты лекции 1 /
Подходы к проектированию в системной инженерии
Чтобы перейти от абстрактных аспектов и их проверки к целям безопасности, давайте обсудим подходы, применяемые в проектировании (а создание целей безопасности из неструктурированного описания – это именно проектирование). Рехтин и Мэйер определяют 4 подхода: нормативный (normative), методический (rational, method-based), кооперационный (participative), эвристический (heuristic). На протяжении курса мы будем неоднократно возвращаться к этой классификации.
Нормативный подход заключается в применении к системе, ее элементам и процессам ЖЦ обязательных требований, включая требования законодательства, государственных и отраслевых регуляторов, но не ограничиваясь этими требованиями.
Методический подход заключается в применении к системе, ее элементам и процессам ЖЦ классического дедуктивного метода проектирования («сверху вниз») – моделей, шаблонов проектирования и разработки, а также формально определенных алгоритмов взаимодействия и протоколов, обеспечивающих передачу данных, контроль и управление, обладающие заданными свойствами.
Кооперационный подход заключается в совместной деятельности заинтересованных лиц – участников процессов ЖЦ системы, целью этой деятельности является учет всех интересов участников при реализации требований к системе. В том числе, кооперационный подход включает реализацию участниками требований к безопасной разработке системы, но не ограничивается им.
Эвристический подход заключается в применении системе принципов и «лучших практик», представляющих результаты извлеченных уроков из предыдущего опыта проектирования (подход «снизу вверх»).
Подходы разделены не строго, могут эволюционировать между собой и видоизменяться, будучи использованы вместе.

Ключевые моменты лекции 1 /
Цели безопасности. Предположения безопасности
Исходя из всего вышесказанного, нам нужно научиться формулировать цели безопасности, обладающие следующими предпочтительными свойствами: 1. Сформулированы в объективной и конкретной манере 2. Желательно, чтобы они были описаны как инвариант, то есть для формулировок нужно использовать описательные выражения (например, описывающие, а не предписывающие эвристики).
Эти цели должны быть определены, исходя из неконсистентного, вероятно неполного перечня интересов, мотивов и побуждений к безопасности, действующего для заинтересованных сторон. При создании системы нередки ситуации конфликта интересов, отсутствия реальной мотивации к трате ресурсов на безопасность и т.п. Поэтому применяем доступные нам методы: лучше всего на первых этапах работают эвристики, неплохо подходит нормативная база, можно использовать кооперационные методы (брейнсторм, совместная работа). Методический подход к анализу конфликта интересов и анализу стратегий должен работать, но на фактически не используется: непрактично. В определении целей безопасности может быть несколько итераций уточнения.
Предположения безопасности как правило, касаются ряда определенных факторов, должны быть сформулированы однозначно и четко. Невысказанные предположения представляют собой риски безопасности или создают почву для рисков.

Имея достаточно деталей о технологии и предполагаемой реализации системы, можно построить модель угроз для системы в целом и ее элементов. Цели безопасности нельзя «заужать», так как дополнительные ограничения еще поступят от реализации их механизмами безопасности. Методы гарантии безопасности применимы к механизмам, исходя из реализации этих механизмов. Тут хорошую службу сослужит правильная архитектура системы: доказательство безопасности может упроститься. Со своей стороны, отдельным интересом заинтересованных сторон может быть получение определенного уровня гарантий.
А вот включение требований к гарантиям безопасности в перечень целей безопасности не является хорошей практикой: лучше, чтобы цели безопасности были объектом валидации. Требование гарантий «внутри» списка целей приведет к «самоприменению» требования и неразрешимости задачи.
Также тонкий момент заключается в том, что, если заинтересованные лица выставляют требования непосредственно к механизмам безопасности в обход формулирования целей, это может привести к неадекватной или неполной реализации безопасности, перерасходу средств, так называемому «театру безопасности» и другим неприятностям. Поэтому формулирование (проектирование) перечня целей и предположений безопасности является обязательным этапом в создании систем secure by design.

Надеюсь, краткое содержание и слайды будут полезны. А мне будет полезной ваша обратная связь. Задавайте вопросы (лучше в конкретном топике), здесь можно оставить общие комментарии к первому дню.

Ключевые моменты лекции 1 /
Методическая схема анализа безопасности
На основе Analytical framework из книги Росса Андерсона рассмотрим удобную схему, предназначенную для построения процесса анализа требований к безопасности системы. Отдельно рассматриваются субъективные параметры: мотивы, интересы, побуждения заинтересованных сторон, в числе которых рассматривается нарушитель. Можно построить модель нарушителя, указав его мотивы, интересы, технические и физические возможности и ограничения. Однако не стоит забывать о других заинтересованных сторонах, несовпадении их интересов, которые могут вызывать дополнительные риски. Стороны часто «играют в труса» и попадают в ситуацию «балансирования на грани», если говорить языком теории игр.
Учитывая все объективные описания субъективных интересов, и применяя методы проектирования, создается список целей безопасности и предположений безопасности.

Слайды к первой лекции

Доброе утро! Вчера поступило некоторое количество вопросов в чате Тимз, сегодня в начале нашей встречи отвечу на все. Обязательно продублирую самые интересные тут. Постараемся сегодня подхватывать вопросы из чата, чтобы отвечать оперативно. Всем хорошего!

Ключевые моменты лекции 2
Место методического подхода
Методический подход к компьютерной безопасности в проектировании систем должен быть встроен в нашу концепцию с целями безопасности и помогать реализовать интересы сторон, которые эти цели определяют. Лучше всего понять место методического подхода помогает схема, приведенная в стандарте ISO/IEC/IEEE 42010 Systems and software engineering — Architecture description. Нас этот стандарт переведен как ГОСТ 57100, можно пользоваться любой версией.

Архитектуру системы составляют так называемые архитектурные представления (views, например, представление безопасности), созданием которых управляют точки зрения (viewpoints) на архитектуру. Эти точки зрения могут, в том числе, включать относящиеся к безопасности – например, точку зрения на моделирование угроз. Задокументированная точка зрения на архитектуру (а это самый настоящий документ, вот шаблон) ссылается на один или несколько видов моделей (model kind). В свою очередь, модель архитектуры (architecture model), отнесенная к одному из таких описанных видов моделей, составляет часть архитектурного представления.

Архитектурный фреймворк по 42010 помогает понять, зачем нужны модели вообще. А вот зачем нужны модели безопасности? Часто модель имеет настолько существенные ограничения, что кажется, детали реализации (так мы называем уязвимости, например 😉) могут сделать ее неприменимой.
Модели безопасности применяются в основном для того, чтобы внятно и формально описать положения политики безопасности и, в конечном счете, определить, выполняется политика безопасности или нет. Хотя у моделей (не только безопасности) много других применений. Подробности можно найти например в книжке «Модельное мышление» - электронная она доступна в корпоративной библиотеке МИФ (не реклама).

Ключевые моменты лекции 2 /
Политики безопасности и модели безопасности
Политики безопасности определяются разнообразнейшим образом. Самый простой – политика безопасности это директива, которая указывает что системе разрешено, а что нет. Самые внимательные слушатели обратили внимание, что определение может быть отнесено не только к security, но и к safety. В самом деле, не разрешено автомобилю ехать в направлении, противоположном движению руля, а химическому производству превышать определенный объем вредных выбросов в окружающую среду. Мы не будем обращать внимание на этот нюанс, тем более что рядом упоминается механизм безопасности – это то, что позволяет политику выполнять.
Модель безопасности – это формальное представление политики безопасности

Ключевые моменты лекции 2 /
Моделирование контроля доступа
Мы рассматриваем модели контроля доступа, как самые распространенные, и самые актуальные на текущий момент. Модели контроля доступа часто используют матрицу доступа: определяется множество субъектов доступа, множество объектов (включая всех субъектов, которые также являются объектами) и множество прав доступа, субъекты и объекты представляют строки и столбцы матрицы, права содержатся в ячейках. Некоторые права являются базовыми правами доступа (чтение, запись, исполнение и т.п.), другие права – контрольные – они влияют на передачу прав доступа субъектам. Матрица доступа может описать любой вид доступа в системе.
Можно описать систему из шести примитивных команд: создание субъекта, создание объектоа, добавление права доступа в ячейку таблицы, удаление права из ячейки, удаление субъекта, удаление объекта. На основе примитивных команд и условного оператора можно определить операции в системе (например запуск процесса или удаление файла в операционной системе). Так моделируется работа системы с механизмом контроля доступа. Эта модель достаточно выразительна, чтобы описать, что происходит в ОС – и не только, можно описать взаимодействие в распределенных системах, работу межсетевого экрана и т.п.

Ключевые моменты лекции 2/
Дискреционный и мандатный контроль доступа
Матрица доступа позволяет описать права доступа на объекты и привилегии субъектов, не зависящие от объекта применения: для привилегии нужно добавить право в ячейку доступа субъекта по отношению к самому себе.
Ранее мы упомянули контрольные права. Они дают ключ к разделению видов контроля доступа.
Дискреционный контроль доступа – это такой, в которой у субъектов внутри модели есть возможность влиять на распределение прав на объекты, в том числе передавать и отнимать права доступа.
Мандатный контроль доступа – у субъектов, вне зависимости от их прав и привилегий, нет возможности влиять на распределение прав на объекты.
Контроль доступа на основе уровней безопасности и т.п. – не является определяющим для мандатной модели! Определяющий фактор для вида контроля доступа – (не)возможность управлять доступом изнутри модели.
Это, кстати, является существенным ограничением для реализации мандатной модели в операционных системах. Для того, чтобы вынести управление доступом «вовне модели», необходимо так продумывать архитектуру системы, чтобы, например, у процессов, которые представляют субъекты, не было реальной возможности никак повлиять на процесс выделения прав и привилегий. Пример такой архитектуры – FLASK.

Ключевые моменты лекции 2/
Дискреционный контроль доступа и разрешимость основного вопроса безопасности
Классическая модель DAC – модель Харрисона, Руззо и Ульмана. Она представлена множествами субъектов, объектов, прав доступа, может быть проиллюстрирована матрицей доступа, и ссылается на множество операций, которые могут быть определены с использованием примитивных команд create object, create subject, enter right into, destroy subject, destroy object, delete right from.
Для произвольной системы могут быть описаны операции, к примеру – системные вызовы UNIX могут быть промоделированы в виде операций. При выполнении каждой операции матрица доступа меняется, в система переходит в другое состояние.

Состояние определяется как небезопасное относительно права r, если это право в некотором состоянии появляется в ячейке, в которой этого права не было в начальном состоянии системы.

Модель Харрисона-Руззо -Ульмана достаточно выразительна, чтобы описать фактически все системы с контролем доступа. Необходимо на ее основе выяснить: можно ли придумать алгоритм определения того, переходит ли система в небезопасное состояние или нет?
К сожалению, удалось только доказать, что задача определения утечки права формально неразрешима. Модель ХРУ по выразительной сложности представляет фактически машину Тьюринга, а вопрос утечки права в некотором состоянии сводится к проблеме остановки машины Тьюринга. Поскольку для произвольной машины Тьюринга проблема остановки неразрешима, это ж относится к проблеме безопасности для ХРУ.
В практическом плане это означает, что ХРУ в ее оригинальном виде бесполезна для решения задачи формального доказательства эффективности контроля доступа для произвольной системы.

Ключевые моменты лекции 2 /
Ограничения на ХРУ и другие модели DAC
Тем не менее, не все так плохо как могло показаться.
Во-первых, мы ударились о стену и теперь знаем где она (пессимисты ударились о дно).
Во-вторых, можно а) поискать ограничения для ХРУ б) поискать другие модели кроме ХРУ в) поискать другое применение для моделей кроме решения основной проблемы безопасности, например презентационные (см.книгу Скотта Пейджа).

Для ограниченной ХРУ результаты следующие. Можно за пару минут доказать, что когда каждая операция содержит ровно одну примитивную команду, вопрос безопасности решается за полиномиальное время. Такая система называется монооперационной и в живой природе не существует. Представьте, что вы можете создать файл, но не можете сразу получить на него право own. Или что удаление объекта не связано с правами на него. В общем, малообещающе.

Еще поисследовав, математики пришли к таким выводам (кто не уснет до конца списка?))
- множество систем, безопасность которых не может быть оценена, является рекурсивно перечислимым.
- существует алгоритм, определяющий безопасность системы, описанной командами без операций create subject и create object. Данный алгоритм имеет полиномиальную сложность.
Системы, описанные командами без операций delete и destroy, называются монотонными (вследствие того, что их размер и сложность только увеличивается).
- проблема определения безопасности в монотонной системе является неразрешимой.
- проблема определения безопасности в монотонной системе с командами, имеющими два условия, является неразрешимой.
- проблема определения безопасности в монотонной системе с моноусловными командами является разрешимой.
- и наконец, проблема определения безопасности в системе с моноусловными командами с операциями create, enter и delete (но без destroy) является разрешимой.

Что же касается прочих моделей, то репрезентационные цели успешно реализуют модели типа Take-Grant, красиво иллюстрирующие трояны, фишинг, кражу прав, сговор и другие подставы, а для матрицы доступа в плане реализации разрешимых моделей отлично работает механизм типизации субъектов и объектов. Это в ряде моделей показал проф.Рави Сандху, автор формализации ролевых моделей, а также дискреционных моделей Schematic Protection Model (SPM), Extended SPM, Typed Access Matrix (TAM) и проч. Лучший результат - для тернарной (с четырьмя условиями) монотонной модели.

Слайды ко второму дню и место для вашей обратной связи

Подумала тут, что объяснять нормальному русскоязычному инженеру разницу между security и safety - примерно то же самое, что объяснять иностранцу разницу между "сидит" и "стоит". Вроде есть признак - согнутые задние конечности у субъекта, который сидит. Но работает он ровно до того момента, пока не доходит до "птица сидит на ветке" и "тарелка стоит на столе".
Вот и вчера, резонный вопрос был, почему теорема безопасности для модели ХРУ называется Safety question. Вот поэтому.
Сегодня продолжаем! Будет MILS. Начинаем в 11 ☺️

❗ВНИМАНИЕ ❗
Завтра (в четверг) начало на час раньше.
Встречаемся в 10 утра.