Надеюсь, краткое содержание и слайды будут полезны. А мне будет полезной ваша обратная связь. Задавайте вопросы (лучше в конкретном топике), здесь можно оставить общие комментарии к первому дню.
👍2
Ключевые моменты лекции 1 /
Методическая схема анализа безопасности
На основе Analytical framework из книги Росса Андерсона рассмотрим удобную схему, предназначенную для построения процесса анализа требований к безопасности системы. Отдельно рассматриваются субъективные параметры: мотивы, интересы, побуждения заинтересованных сторон, в числе которых рассматривается нарушитель. Можно построить модель нарушителя, указав его мотивы, интересы, технические и физические возможности и ограничения. Однако не стоит забывать о других заинтересованных сторонах, несовпадении их интересов, которые могут вызывать дополнительные риски. Стороны часто «играют в труса» и попадают в ситуацию «балансирования на грани», если говорить языком теории игр.
Учитывая все объективные описания субъективных интересов, и применяя методы проектирования, создается список целей безопасности и предположений безопасности.
Методическая схема анализа безопасности
На основе Analytical framework из книги Росса Андерсона рассмотрим удобную схему, предназначенную для построения процесса анализа требований к безопасности системы. Отдельно рассматриваются субъективные параметры: мотивы, интересы, побуждения заинтересованных сторон, в числе которых рассматривается нарушитель. Можно построить модель нарушителя, указав его мотивы, интересы, технические и физические возможности и ограничения. Однако не стоит забывать о других заинтересованных сторонах, несовпадении их интересов, которые могут вызывать дополнительные риски. Стороны часто «играют в труса» и попадают в ситуацию «балансирования на грани», если говорить языком теории игр.
Учитывая все объективные описания субъективных интересов, и применяя методы проектирования, создается список целей безопасности и предположений безопасности.
Доброе утро! Вчера поступило некоторое количество вопросов в чате Тимз, сегодня в начале нашей встречи отвечу на все. Обязательно продублирую самые интересные тут. Постараемся сегодня подхватывать вопросы из чата, чтобы отвечать оперативно. Всем хорошего!
Ключевые моменты лекции 2
Место методического подхода
Методический подход к компьютерной безопасности в проектировании систем должен быть встроен в нашу концепцию с целями безопасности и помогать реализовать интересы сторон, которые эти цели определяют. Лучше всего понять место методического подхода помогает схема, приведенная в стандарте ISO/IEC/IEEE 42010 Systems and software engineering — Architecture description. Нас этот стандарт переведен как ГОСТ 57100, можно пользоваться любой версией.
Место методического подхода
Методический подход к компьютерной безопасности в проектировании систем должен быть встроен в нашу концепцию с целями безопасности и помогать реализовать интересы сторон, которые эти цели определяют. Лучше всего понять место методического подхода помогает схема, приведенная в стандарте ISO/IEC/IEEE 42010 Systems and software engineering — Architecture description. Нас этот стандарт переведен как ГОСТ 57100, можно пользоваться любой версией.
Архитектуру системы составляют так называемые архитектурные представления (views, например, представление безопасности), созданием которых управляют точки зрения (viewpoints) на архитектуру. Эти точки зрения могут, в том числе, включать относящиеся к безопасности – например, точку зрения на моделирование угроз. Задокументированная точка зрения на архитектуру (а это самый настоящий документ, вот шаблон) ссылается на один или несколько видов моделей (model kind). В свою очередь, модель архитектуры (architecture model), отнесенная к одному из таких описанных видов моделей, составляет часть архитектурного представления.
Computer security basics
Архитектуру системы составляют так называемые архитектурные представления (views, например, представление безопасности), созданием которых управляют точки зрения (viewpoints) на архитектуру. Эти точки зрения могут, в том числе, включать относящиеся к безопасности…
Архитектурный фреймворк по 42010 помогает понять, зачем нужны модели вообще. А вот зачем нужны модели безопасности? Часто модель имеет настолько существенные ограничения, что кажется, детали реализации (так мы называем уязвимости, например 😉) могут сделать ее неприменимой.
Модели безопасности применяются в основном для того, чтобы внятно и формально описать положения политики безопасности и, в конечном счете, определить, выполняется политика безопасности или нет. Хотя у моделей (не только безопасности) много других применений. Подробности можно найти например в книжке «Модельное мышление» - электронная она доступна в корпоративной библиотеке МИФ (не реклама).
Модели безопасности применяются в основном для того, чтобы внятно и формально описать положения политики безопасности и, в конечном счете, определить, выполняется политика безопасности или нет. Хотя у моделей (не только безопасности) много других применений. Подробности можно найти например в книжке «Модельное мышление» - электронная она доступна в корпоративной библиотеке МИФ (не реклама).
Ключевые моменты лекции 2 /
Политики безопасности и модели безопасности
Политики безопасности определяются разнообразнейшим образом. Самый простой – политика безопасности это директива, которая указывает что системе разрешено, а что нет. Самые внимательные слушатели обратили внимание, что определение может быть отнесено не только к security, но и к safety. В самом деле, не разрешено автомобилю ехать в направлении, противоположном движению руля, а химическому производству превышать определенный объем вредных выбросов в окружающую среду. Мы не будем обращать внимание на этот нюанс, тем более что рядом упоминается механизм безопасности – это то, что позволяет политику выполнять.
Модель безопасности – это формальное представление политики безопасности
Политики безопасности и модели безопасности
Политики безопасности определяются разнообразнейшим образом. Самый простой – политика безопасности это директива, которая указывает что системе разрешено, а что нет. Самые внимательные слушатели обратили внимание, что определение может быть отнесено не только к security, но и к safety. В самом деле, не разрешено автомобилю ехать в направлении, противоположном движению руля, а химическому производству превышать определенный объем вредных выбросов в окружающую среду. Мы не будем обращать внимание на этот нюанс, тем более что рядом упоминается механизм безопасности – это то, что позволяет политику выполнять.
Модель безопасности – это формальное представление политики безопасности
Ключевые моменты лекции 2 /
Моделирование контроля доступа
Мы рассматриваем модели контроля доступа, как самые распространенные, и самые актуальные на текущий момент. Модели контроля доступа часто используют матрицу доступа: определяется множество субъектов доступа, множество объектов (включая всех субъектов, которые также являются объектами) и множество прав доступа, субъекты и объекты представляют строки и столбцы матрицы, права содержатся в ячейках. Некоторые права являются базовыми правами доступа (чтение, запись, исполнение и т.п.), другие права – контрольные – они влияют на передачу прав доступа субъектам. Матрица доступа может описать любой вид доступа в системе.
Можно описать систему из шести примитивных команд: создание субъекта, создание объектоа, добавление права доступа в ячейку таблицы, удаление права из ячейки, удаление субъекта, удаление объекта. На основе примитивных команд и условного оператора можно определить операции в системе (например запуск процесса или удаление файла в операционной системе). Так моделируется работа системы с механизмом контроля доступа. Эта модель достаточно выразительна, чтобы описать, что происходит в ОС – и не только, можно описать взаимодействие в распределенных системах, работу межсетевого экрана и т.п.
Моделирование контроля доступа
Мы рассматриваем модели контроля доступа, как самые распространенные, и самые актуальные на текущий момент. Модели контроля доступа часто используют матрицу доступа: определяется множество субъектов доступа, множество объектов (включая всех субъектов, которые также являются объектами) и множество прав доступа, субъекты и объекты представляют строки и столбцы матрицы, права содержатся в ячейках. Некоторые права являются базовыми правами доступа (чтение, запись, исполнение и т.п.), другие права – контрольные – они влияют на передачу прав доступа субъектам. Матрица доступа может описать любой вид доступа в системе.
Можно описать систему из шести примитивных команд: создание субъекта, создание объектоа, добавление права доступа в ячейку таблицы, удаление права из ячейки, удаление субъекта, удаление объекта. На основе примитивных команд и условного оператора можно определить операции в системе (например запуск процесса или удаление файла в операционной системе). Так моделируется работа системы с механизмом контроля доступа. Эта модель достаточно выразительна, чтобы описать, что происходит в ОС – и не только, можно описать взаимодействие в распределенных системах, работу межсетевого экрана и т.п.
👍1
Ключевые моменты лекции 2/
Дискреционный и мандатный контроль доступа
Матрица доступа позволяет описать права доступа на объекты и привилегии субъектов, не зависящие от объекта применения: для привилегии нужно добавить право в ячейку доступа субъекта по отношению к самому себе.
Ранее мы упомянули контрольные права. Они дают ключ к разделению видов контроля доступа.
Дискреционный контроль доступа – это такой, в которой у субъектов внутри модели есть возможность влиять на распределение прав на объекты, в том числе передавать и отнимать права доступа.
Мандатный контроль доступа – у субъектов, вне зависимости от их прав и привилегий, нет возможности влиять на распределение прав на объекты.
Контроль доступа на основе уровней безопасности и т.п. – не является определяющим для мандатной модели! Определяющий фактор для вида контроля доступа – (не)возможность управлять доступом изнутри модели.
Это, кстати, является существенным ограничением для реализации мандатной модели в операционных системах. Для того, чтобы вынести управление доступом «вовне модели», необходимо так продумывать архитектуру системы, чтобы, например, у процессов, которые представляют субъекты, не было реальной возможности никак повлиять на процесс выделения прав и привилегий. Пример такой архитектуры – FLASK.
Дискреционный и мандатный контроль доступа
Матрица доступа позволяет описать права доступа на объекты и привилегии субъектов, не зависящие от объекта применения: для привилегии нужно добавить право в ячейку доступа субъекта по отношению к самому себе.
Ранее мы упомянули контрольные права. Они дают ключ к разделению видов контроля доступа.
Дискреционный контроль доступа – это такой, в которой у субъектов внутри модели есть возможность влиять на распределение прав на объекты, в том числе передавать и отнимать права доступа.
Мандатный контроль доступа – у субъектов, вне зависимости от их прав и привилегий, нет возможности влиять на распределение прав на объекты.
Контроль доступа на основе уровней безопасности и т.п. – не является определяющим для мандатной модели! Определяющий фактор для вида контроля доступа – (не)возможность управлять доступом изнутри модели.
Это, кстати, является существенным ограничением для реализации мандатной модели в операционных системах. Для того, чтобы вынести управление доступом «вовне модели», необходимо так продумывать архитектуру системы, чтобы, например, у процессов, которые представляют субъекты, не было реальной возможности никак повлиять на процесс выделения прав и привилегий. Пример такой архитектуры – FLASK.
Ключевые моменты лекции 2/
Дискреционный контроль доступа и разрешимость основного вопроса безопасности
Классическая модель DAC – модель Харрисона, Руззо и Ульмана. Она представлена множествами субъектов, объектов, прав доступа, может быть проиллюстрирована матрицей доступа, и ссылается на множество операций, которые могут быть определены с использованием примитивных команд create object, create subject, enter right into, destroy subject, destroy object, delete right from.
Для произвольной системы могут быть описаны операции, к примеру – системные вызовы UNIX могут быть промоделированы в виде операций. При выполнении каждой операции матрица доступа меняется, в система переходит в другое состояние.
Состояние определяется как небезопасное относительно права r, если это право в некотором состоянии появляется в ячейке, в которой этого права не было в начальном состоянии системы.
Модель Харрисона-Руззо -Ульмана достаточно выразительна, чтобы описать фактически все системы с контролем доступа. Необходимо на ее основе выяснить: можно ли придумать алгоритм определения того, переходит ли система в небезопасное состояние или нет?
К сожалению, удалось только доказать, что задача определения утечки права формально неразрешима. Модель ХРУ по выразительной сложности представляет фактически машину Тьюринга, а вопрос утечки права в некотором состоянии сводится к проблеме остановки машины Тьюринга. Поскольку для произвольной машины Тьюринга проблема остановки неразрешима, это ж относится к проблеме безопасности для ХРУ.
В практическом плане это означает, что ХРУ в ее оригинальном виде бесполезна для решения задачи формального доказательства эффективности контроля доступа для произвольной системы.
Дискреционный контроль доступа и разрешимость основного вопроса безопасности
Классическая модель 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) является разрешимой.
Ограничения на ХРУ и другие модели DAC
Тем не менее, не все так плохо как могло показаться.
Во-первых, мы ударились о стену и теперь знаем где она (пессимисты ударились о дно).
Во-вторых, можно а) поискать ограничения для ХРУ б) поискать другие модели кроме ХРУ в) поискать другое применение для моделей кроме решения основной проблемы безопасности, например презентационные (см.книгу Скотта Пейджа).
Для ограниченной ХРУ результаты следующие. Можно за пару минут доказать, что когда каждая операция содержит ровно одну примитивную команду, вопрос безопасности решается за полиномиальное время. Такая система называется монооперационной и в живой природе не существует. Представьте, что вы можете создать файл, но не можете сразу получить на него право own. Или что удаление объекта не связано с правами на него. В общем, малообещающе.
Еще поисследовав, математики пришли к таким выводам (кто не уснет до конца списка?))
- множество систем, безопасность которых не может быть оценена, является рекурсивно перечислимым.
- существует алгоритм, определяющий безопасность системы, описанной командами без операций create subject и create object. Данный алгоритм имеет полиномиальную сложность.
Системы, описанные командами без операций delete и destroy, называются монотонными (вследствие того, что их размер и сложность только увеличивается).
- проблема определения безопасности в монотонной системе является неразрешимой.
- проблема определения безопасности в монотонной системе с командами, имеющими два условия, является неразрешимой.
- проблема определения безопасности в монотонной системе с моноусловными командами является разрешимой.
- и наконец, проблема определения безопасности в системе с моноусловными командами с операциями create, enter и delete (но без destroy) является разрешимой.
👍2
Computer security basics
Ключевые моменты лекции 2 / Ограничения на ХРУ и другие модели DAC Тем не менее, не все так плохо как могло показаться. Во-первых, мы ударились о стену и теперь знаем где она (пессимисты ударились о дно). Во-вторых, можно а) поискать ограничения для ХРУ…
Что же касается прочих моделей, то репрезентационные цели успешно реализуют модели типа Take-Grant, красиво иллюстрирующие трояны, фишинг, кражу прав, сговор и другие подставы, а для матрицы доступа в плане реализации разрешимых моделей отлично работает механизм типизации субъектов и объектов. Это в ряде моделей показал проф.Рави Сандху, автор формализации ролевых моделей, а также дискреционных моделей Schematic Protection Model (SPM), Extended SPM, Typed Access Matrix (TAM) и проч. Лучший результат - для тернарной (с четырьмя условиями) монотонной модели.
Подумала тут, что объяснять нормальному русскоязычному инженеру разницу между security и safety - примерно то же самое, что объяснять иностранцу разницу между "сидит" и "стоит". Вроде есть признак - согнутые задние конечности у субъекта, который сидит. Но работает он ровно до того момента, пока не доходит до "птица сидит на ветке" и "тарелка стоит на столе".
Вот и вчера, резонный вопрос был, почему теорема безопасности для модели ХРУ называется Safety question. Вот поэтому.
Сегодня продолжаем! Будет MILS. Начинаем в 11 ☺️
Вот и вчера, резонный вопрос был, почему теорема безопасности для модели ХРУ называется Safety question. Вот поэтому.
Сегодня продолжаем! Будет MILS. Начинаем в 11 ☺️
👍8
❗ВНИМАНИЕ ❗
Завтра (в четверг) начало на час раньше.
Встречаемся в 10 утра.
Завтра (в четверг) начало на час раньше.
Встречаемся в 10 утра.
👍5
Ключевые моменты лекции 3 /
Модель мандатного управления доступом. Модель Белла-Лападула
Идеи, лежащие в основе модели Белла и Лападула, берут происхождение из «бумажного мира». Белл и Лападула перенесли модель безопасности, принятую при работе с докумен¬тами, в мир компьютерных систем. Основным наблюдением, сделанным Беллом и Лападулой, является то, что в правительстве США все субъекты и объекты ассоциируются с уровнями секретности, варьирующимися от низких уровней (неклассифицированных) до высоких (совершенно секретных). Кроме того, они обнаружили, что для предотвращения утечки информации к неуполномоченным субъектам, этим субъектам с низкими уровнями секретности не позволяется чи¬тать информацию из объектов с высокими уровнями секретности. Получилось два эмпирических правила: No Read Up, No Write Down.
В модели объектам и субъектам присваиваются упорядоченные уровни. Получается математическая структура – решетка. Кроме того, каждый объект может быть отнесен к некоторый категории, например к проекту.
Модель мандатного управления доступом. Модель Белла-Лападула
Идеи, лежащие в основе модели Белла и Лападула, берут происхождение из «бумажного мира». Белл и Лападула перенесли модель безопасности, принятую при работе с докумен¬тами, в мир компьютерных систем. Основным наблюдением, сделанным Беллом и Лападулой, является то, что в правительстве США все субъекты и объекты ассоциируются с уровнями секретности, варьирующимися от низких уровней (неклассифицированных) до высоких (совершенно секретных). Кроме того, они обнаружили, что для предотвращения утечки информации к неуполномоченным субъектам, этим субъектам с низкими уровнями секретности не позволяется чи¬тать информацию из объектов с высокими уровнями секретности. Получилось два эмпирических правила: No Read Up, No Write Down.
В модели объектам и субъектам присваиваются упорядоченные уровни. Получается математическая структура – решетка. Кроме того, каждый объект может быть отнесен к некоторый категории, например к проекту.
Computer security basics
Ключевые моменты лекции 3 / Модель мандатного управления доступом. Модель Белла-Лападула Идеи, лежащие в основе модели Белла и Лападула, берут происхождение из «бумажного мира». Белл и Лападула перенесли модель безопасности, принятую при работе с докумен¬тами…
Множество категорий и его подмножества также упорядочены и точно так же образуют решетку. Если эти отношения порядка объединить логическим «И», снова получится отношение порядка. Вот это отношение является основным для модели. С практической точки зрения его легко объяснить: субъекту можно получить доступ к объекту по чтению, если объект не является секретным для уровня допуска субъекта, и субъект работает над соответствующим проектом.
Состояние системы считается безопасным, если оно отвечает формализованным правилам по доступу NRU и NWD. Основная теорема безопасности для модели Белла и ЛаПадула формулируется и доказывается по индукции достаточно очевидным образом: система безопасна тогда и только тогда, когда она безопасна в начальном состоянии, и переходы в другое состояние подчиняются ограничениям, сохраняющим условия NRU и NWD.
Состояние системы считается безопасным, если оно отвечает формализованным правилам по доступу NRU и NWD. Основная теорема безопасности для модели Белла и ЛаПадула формулируется и доказывается по индукции достаточно очевидным образом: система безопасна тогда и только тогда, когда она безопасна в начальном состоянии, и переходы в другое состояние подчиняются ограничениям, сохраняющим условия NRU и NWD.