Ключевые моменты лекции 3 /
Архитектурный подход MILS. Требования к реализации
Существенным для определения системы как MILS системы является не только использование комбинации архитектуры и политики как формальной модели, основанной на моделях безопасности, но и должная реализация этой модели на основе подходящих технологий. Реализация должна исключать возможность непредусмотренного взаимодействия доменов, в том числе на уровне аппаратных средств. В том числе поэтому применяются требования к CPU, MMU, IOMMU.
В основе разделения доменов лежит так называемое ядро разделения (Separation Kernel). Ядро разделения – это механизм, обеспечивающий как изоляцию, так и управление информационными потоками.
Задача ядра разделения – создать среду, которая неотличима от среды, предоставляемой физически распределенной системой.
Он должен выглядеть так, как будто каждый режим представляет собой отдельную изолированную машину, и эта информация может передаваться только от одной машины к другой по известным внешним линиям связи.
Архитектурный подход MILS. Требования к реализации
Существенным для определения системы как MILS системы является не только использование комбинации архитектуры и политики как формальной модели, основанной на моделях безопасности, но и должная реализация этой модели на основе подходящих технологий. Реализация должна исключать возможность непредусмотренного взаимодействия доменов, в том числе на уровне аппаратных средств. В том числе поэтому применяются требования к CPU, MMU, IOMMU.
В основе разделения доменов лежит так называемое ядро разделения (Separation Kernel). Ядро разделения – это механизм, обеспечивающий как изоляцию, так и управление информационными потоками.
Задача ядра разделения – создать среду, которая неотличима от среды, предоставляемой физически распределенной системой.
Он должен выглядеть так, как будто каждый режим представляет собой отдельную изолированную машину, и эта информация может передаваться только от одной машины к другой по известным внешним линиям связи.
Ключевые моменты лекции 3 /
Архитектурный подход MILS. Функции ядра разделения
Ядро разделения обеспечивает пространственное и временное разделение доменов, но позволяет им взаимодействовать контролируемым образом. Степень, в которой изоляция обеспечивается посредством каждого из этих типов разделения, зависит от цели системы и конкретного архитектурного проекта.
Пространственное разделение обеспечивает разделение данных, управление информационным потоком и изоляцию отказов. Разделение данных означает, что каждый домен развернут как отдельный ресурс. Приложения в одном домене не могут ни косвенно влиять на данные в других доменах, ни контролировать приложения и устройства в них. Управление потоками данных обеспечивает только авторизованную передачу данных и сигналов управления между доменами. Изоляция отказов ограничивает распространение отказов от одного домена к другому.
Временное разделение поддерживает планирование операций в различное время и поддерживает меры по предотвращению совместного использования ресурсов доменами в один временной промежуток. Очистка ресурсов (sanitization) гарантирует, что области данных в домене очищаются, когда система переключается на обработку данных в других доменах. Это также помогает смягчить атаки «холодной загрузки» и другие атаки на конфиденциальные данные внутри доменов.
Базовые функциональные возможности ядра разделения включают:
✔️ разделение доменов безопасности,
✔️ поддержка междоменных коммуникаций,
✔️ соблюдение политики безопасности,
✔️ управление памятью,
✔️ планирование,
✔️ обработка периодов и очистка ресурсов,
✔️ минимальное обслуживание прерываний,
✔️ минимальные примитивы синхронизации, таймеры и сторожевые таймеры,
✔️ инструментация (при необходимости).
Ядро разделения создает распределенную среду в рамках одного хоста. Однако существует идея (и даже реализация) распределенного MILS, который создает гомогенную MILS среду поверх компьютерной сети. В этом случае сетевая подсистема также составляет часть ядра разделения, и к ней будут применяться определенные требования – к оборудованию, ПО и сетевым протоколам – для корректной реализации и управления доменами MILS.
Архитектурный подход MILS. Функции ядра разделения
Ядро разделения обеспечивает пространственное и временное разделение доменов, но позволяет им взаимодействовать контролируемым образом. Степень, в которой изоляция обеспечивается посредством каждого из этих типов разделения, зависит от цели системы и конкретного архитектурного проекта.
Пространственное разделение обеспечивает разделение данных, управление информационным потоком и изоляцию отказов. Разделение данных означает, что каждый домен развернут как отдельный ресурс. Приложения в одном домене не могут ни косвенно влиять на данные в других доменах, ни контролировать приложения и устройства в них. Управление потоками данных обеспечивает только авторизованную передачу данных и сигналов управления между доменами. Изоляция отказов ограничивает распространение отказов от одного домена к другому.
Временное разделение поддерживает планирование операций в различное время и поддерживает меры по предотвращению совместного использования ресурсов доменами в один временной промежуток. Очистка ресурсов (sanitization) гарантирует, что области данных в домене очищаются, когда система переключается на обработку данных в других доменах. Это также помогает смягчить атаки «холодной загрузки» и другие атаки на конфиденциальные данные внутри доменов.
Базовые функциональные возможности ядра разделения включают:
✔️ разделение доменов безопасности,
✔️ поддержка междоменных коммуникаций,
✔️ соблюдение политики безопасности,
✔️ управление памятью,
✔️ планирование,
✔️ обработка периодов и очистка ресурсов,
✔️ минимальное обслуживание прерываний,
✔️ минимальные примитивы синхронизации, таймеры и сторожевые таймеры,
✔️ инструментация (при необходимости).
Ядро разделения создает распределенную среду в рамках одного хоста. Однако существует идея (и даже реализация) распределенного MILS, который создает гомогенную MILS среду поверх компьютерной сети. В этом случае сетевая подсистема также составляет часть ядра разделения, и к ней будут применяться определенные требования – к оборудованию, ПО и сетевым протоколам – для корректной реализации и управления доменами MILS.
👍1
Computer security basics pinned «❗ВНИМАНИЕ ❗ Завтра (в четверг) начало на час раньше. Встречаемся в 10 утра.»
CSB - Part3.pdf
2.8 MB
Слайды к третьей лекции и место для вашей обратной связи
Ключевые моменты лекции 4 /
Assurance / Гарантии безопасности
Assurance, если посмотреть в ISO 15026 или ГОСТ 15026, это «основание для утверждения, что требование выполнено или будет выполнено». Это основание может быть получено различными методами, обычно говорят о методике assurance. При этом часто ссылаются на следующие понятия:
Claim (переводится в ГОСТ как «претензия») – утверждение типа "истина/ложь" о выполнении ограничений на значения однозначно определенных свойств (называемых связанными с претензией свойствами), а также ограничений на неопределенность значений свойств в пределах этих ограничений в случае применимости претензии при указанных условиях.
Для нас эти свойства, к примеру, это наши цели безопасности и предположения безопасности. Вспоминаем стрелочку между квадратиками Security Objectives и Assurance на схеме анализа из первой лекции.
Assurance Case (переводится как, о ужас, «гарантийный случай») - обоснованный проверяемый артефакт, подтверждающий, что удовлетворяется claim верхнего уровня (или совокупность claims), и включающий систематическую аргументацию и ее явные предположения. То есть это как теорема с доказательством и леммами.
Еще пара определений. Часто говорят о compliance и conformance. Compliance – это обязательное соответствие некоторому набору требований (например, регулятора), достигаемое посредством получения assurance. Conformance – это добровольное соответствие, то есть использование требований/проверка на соответствие по желанию (просто иногда удобно использовать готовый набор требований).
Assurance / Гарантии безопасности
Assurance, если посмотреть в ISO 15026 или ГОСТ 15026, это «основание для утверждения, что требование выполнено или будет выполнено». Это основание может быть получено различными методами, обычно говорят о методике assurance. При этом часто ссылаются на следующие понятия:
Claim (переводится в ГОСТ как «претензия») – утверждение типа "истина/ложь" о выполнении ограничений на значения однозначно определенных свойств (называемых связанными с претензией свойствами), а также ограничений на неопределенность значений свойств в пределах этих ограничений в случае применимости претензии при указанных условиях.
Для нас эти свойства, к примеру, это наши цели безопасности и предположения безопасности. Вспоминаем стрелочку между квадратиками Security Objectives и Assurance на схеме анализа из первой лекции.
Assurance Case (переводится как, о ужас, «гарантийный случай») - обоснованный проверяемый артефакт, подтверждающий, что удовлетворяется claim верхнего уровня (или совокупность claims), и включающий систематическую аргументацию и ее явные предположения. То есть это как теорема с доказательством и леммами.
Еще пара определений. Часто говорят о compliance и conformance. Compliance – это обязательное соответствие некоторому набору требований (например, регулятора), достигаемое посредством получения assurance. Conformance – это добровольное соответствие, то есть использование требований/проверка на соответствие по желанию (просто иногда удобно использовать готовый набор требований).
docs.cntd.ru
ГОСТ Р ИСО/МЭК 15026-1-2016 Системная и программная инженерия. Гарантирование систем и программного обеспечения. Часть 1. Понятия…
ГОСТ Р ИСО/МЭК 15026-1-2016 Системная и программная инженерия. Гарантирование систем и программного обеспечения. Часть 1. Понятия и словарь - ГОСТ Р № ИСО/МЭК 15026-1-2016
Ключевые моменты лекции 4 /
Валидация и верификация
(вы их больше не перепутаете)
Гарантии безопасности достигаются через валидацию и верификацию (ПО).
Верификация и валидация используются для проверки того факта, что система, программа или аппаратное устройство в действительности обладает ожидаемыми свойствами. Эти два понятия (V&V) хоть и схожи по звучанию и постоянно используются вместе, означают существенно разные типы проверок.
Верификация – это процесс оценки того, насколько система (программа, устройство) по итогам некоторого этапа ее разработки соответствует условиям, заданным в начале этапа.
Валидация – процесс оценки того, насколько система (программа, устройство) соответствует требованиям по ее назначению.
Если говорить еще проще, верификация задается вопросом, строим ли мы систему правильно, а валидация – строим ли мы правильную систему.
Как валидация, так и верификация могут применяться на всех этапах разработки ПО. Объектом приложения верификации является не только сама система, но, к примеру, и набор требований к этой системе. При проведении валидации проверяется соответствие требованиям более высокого уровня, а верификация отвечает за полноту, согласованность, внутреннюю непротиворечивость набора требований и т.п.
Я когда-то давно писала статью на securelist, в ней можно найти больше букв на эту тему. Вот она на русском, вот на английском.
Валидация и верификация
(вы их больше не перепутаете)
Гарантии безопасности достигаются через валидацию и верификацию (ПО).
Верификация и валидация используются для проверки того факта, что система, программа или аппаратное устройство в действительности обладает ожидаемыми свойствами. Эти два понятия (V&V) хоть и схожи по звучанию и постоянно используются вместе, означают существенно разные типы проверок.
Верификация – это процесс оценки того, насколько система (программа, устройство) по итогам некоторого этапа ее разработки соответствует условиям, заданным в начале этапа.
Валидация – процесс оценки того, насколько система (программа, устройство) соответствует требованиям по ее назначению.
Если говорить еще проще, верификация задается вопросом, строим ли мы систему правильно, а валидация – строим ли мы правильную систему.
Как валидация, так и верификация могут применяться на всех этапах разработки ПО. Объектом приложения верификации является не только сама система, но, к примеру, и набор требований к этой системе. При проведении валидации проверяется соответствие требованиям более высокого уровня, а верификация отвечает за полноту, согласованность, внутреннюю непротиворечивость набора требований и т.п.
Я когда-то давно писала статью на securelist, в ней можно найти больше букв на эту тему. Вот она на русском, вот на английском.
securelist.ru
Валидация и верификация
Безопасная система – и в особенности система, которая используется для обеспечения безопасности – должны быть доверенной. Однако что лежит в основе этого доверия? Что придает уверенность в том, что основные компоненты системы реализованы правильно и не подведут…
Ключевые моменты лекции 4 /
Методы верификации
Верификация может проводиться динамическими или статическими методами.
Динамические методы требуют запуска программного кода на исполнение либо его эмуляции. К динамической верификации относится всем известное тестирование, фаззинг, отладка, эмуляция, вспомогательные методы типа инструментации кода и т.д.
Статические методы включают исследование и проверку кода, анализ кода автоматическими средствами для поиска опасных конструкций, сбор специфичных метрик кода, формальную верификацию.
Вспомогательным методом для статанализа является введение ограничений на язык программирование и использование опасных или сложных для анализа языковых конструкций.
Недостатком динамических методов является неполнота тестирования, статических – потенциальная неполнота результатов для неформальных методов и вычислительная сложность для формальных.
Наилучшие результаты показывает совмещение динамики и статики в верификации программного кода.
Методы верификации
Верификация может проводиться динамическими или статическими методами.
Динамические методы требуют запуска программного кода на исполнение либо его эмуляции. К динамической верификации относится всем известное тестирование, фаззинг, отладка, эмуляция, вспомогательные методы типа инструментации кода и т.д.
Статические методы включают исследование и проверку кода, анализ кода автоматическими средствами для поиска опасных конструкций, сбор специфичных метрик кода, формальную верификацию.
Вспомогательным методом для статанализа является введение ограничений на язык программирование и использование опасных или сложных для анализа языковых конструкций.
Недостатком динамических методов является неполнота тестирования, статических – потенциальная неполнота результатов для неформальных методов и вычислительная сложность для формальных.
Наилучшие результаты показывает совмещение динамики и статики в верификации программного кода.
Ключевые моменты лекции 4 /
Формальная верификация
Дисклеймер: поскольку я не занимаюсь формальной верификацией ПО на постоянной основе и каждый день, а область эта постоянно развивается, я дам основные понятия и ссылки. Есть области, например формальная верификация ПО, и еще криптография, где я обладаю некоторыми знаниями, но не считаю себя экспертом – для этого пришлось бы уделять им все имеющееся у меня время.
Тем не менее, перечислим известные и применяемые методы формальной верификации. Во-первых, это model checking (проверка на модели) - метод автоматической формальной верификации параллельных систем с конечным числом состояний, позволяет проверить, удовлетворяет ли заданная модель системы формальным спецификациям.
В качестве спецификации обычно используется модель, основанная на множестве состояний, включая множество начальных состояний, отношении переходов между состояниями и т.н. функция разметки (модель Крипке).
Обычно спецификации задаются на языке формальной логики, для ПО особенно удобно использовать темпоральную логику — булеву логику с добавлением операторов времени.
Для проверки на модели особенно важно проверить полноту спецификации модели. Если спецификация модели не охватывает все нужные свойства, то результаты проверки будут малополезны.
Основной проблемой для проверки на модели является возможный «экспоненциальный взрыв» сложности проверок.
Метод дедуктивной верификации реализует проверку правильности программы относительно ее спецификации, записанной на формальном языке спецификаций. Условия корректности программы генерируются автоматически по формулам логики и спецификации программы путем применения системы логических правил. Доказательство условий корректности проводится с помощью некоторой системы автоматического доказательства. Метод ограничен ситуациями математической неразрешимости.
Кроме этих двух методов, множество авторов упоминают множество других методов. Некоторые из них действительно существенно отличаются (например, вовлекают динамические методы), другие представляют собой комбинации или улучшения известных. Мы рассматривали также методы уточнения и генерации кода (refinement and code generation) и метод абстрактной интерпретации (abstract interpretation) описываемый в неплохой статье парой европейских ученых.
Источники
Книга Ю.Г.Карпов «Model Checking»
Слайды к лекциям на ВМК МГУ, содержат в т.ч. примеры из книжки Ю.Г.Карпова и компиляцию полезной информации по формальным методам
Слайды к курсу лекций в СПб Политехе
Методичка к курсу лекций в МГУ от автора из ИСП РАН
Материалы Института системного программирования РАН (ИСП РАН)
Формальная верификация
Дисклеймер: поскольку я не занимаюсь формальной верификацией ПО на постоянной основе и каждый день, а область эта постоянно развивается, я дам основные понятия и ссылки. Есть области, например формальная верификация ПО, и еще криптография, где я обладаю некоторыми знаниями, но не считаю себя экспертом – для этого пришлось бы уделять им все имеющееся у меня время.
Тем не менее, перечислим известные и применяемые методы формальной верификации. Во-первых, это model checking (проверка на модели) - метод автоматической формальной верификации параллельных систем с конечным числом состояний, позволяет проверить, удовлетворяет ли заданная модель системы формальным спецификациям.
В качестве спецификации обычно используется модель, основанная на множестве состояний, включая множество начальных состояний, отношении переходов между состояниями и т.н. функция разметки (модель Крипке).
Обычно спецификации задаются на языке формальной логики, для ПО особенно удобно использовать темпоральную логику — булеву логику с добавлением операторов времени.
Для проверки на модели особенно важно проверить полноту спецификации модели. Если спецификация модели не охватывает все нужные свойства, то результаты проверки будут малополезны.
Основной проблемой для проверки на модели является возможный «экспоненциальный взрыв» сложности проверок.
Метод дедуктивной верификации реализует проверку правильности программы относительно ее спецификации, записанной на формальном языке спецификаций. Условия корректности программы генерируются автоматически по формулам логики и спецификации программы путем применения системы логических правил. Доказательство условий корректности проводится с помощью некоторой системы автоматического доказательства. Метод ограничен ситуациями математической неразрешимости.
Кроме этих двух методов, множество авторов упоминают множество других методов. Некоторые из них действительно существенно отличаются (например, вовлекают динамические методы), другие представляют собой комбинации или улучшения известных. Мы рассматривали также методы уточнения и генерации кода (refinement and code generation) и метод абстрактной интерпретации (abstract interpretation) описываемый в неплохой статье парой европейских ученых.
Источники
Книга Ю.Г.Карпов «Model Checking»
Слайды к лекциям на ВМК МГУ, содержат в т.ч. примеры из книжки Ю.Г.Карпова и компиляцию полезной информации по формальным методам
Слайды к курсу лекций в СПб Политехе
Методичка к курсу лекций в МГУ от автора из ИСП РАН
Материалы Института системного программирования РАН (ИСП РАН)
👍2
Ключевые моменты лекции 4 /
Гарантии безопасности в MILS
Сама идея развития MILS, начиная где-то с 2010, включала идею поставки компонентов разными разработчиками с готовыми assurance cases на типовые для этих компонентов цели безопасности. Если при совмещении компонентов не возникает новых свойств, влияющих на нарушение гарантий, то такая система автоматически получает унаследованные от компонентов гарантии безопасности.
Для этого ввели три специальных свойства:
Компонуемость (composability) — условие, при котором компоненты могут быть составлены без ущерба для их индивидуальных свойств. Это важнейшее свойство, предоставляемое ядром разделения (или платформой MILS). Компоненты А и В могут выполняться изолированно, и ни один из них не влияет на работу другого.
Композиционность (compositionality) — условие, при котором компоненты могут быть составлены таким образом, чтобы создавать новые свойства композиции из их индивидуальных свойств. Композиционность представляет собой способность соединять два компонента таким образом, чтобы их поведение конструктивно комбинировалось для создания нового поведения.
Аддитивность (или аддитивная композиционность) (additivity) — особый вид композиционности, при котором «дополнение» отдельных, но различных свойств компонентов сохраняется в композиции наряду с их общими свойствами. Эта концепция необходима для обеспечения составления платформы MILS из основных компонентов MILS.
Гарантии безопасности в MILS
Сама идея развития MILS, начиная где-то с 2010, включала идею поставки компонентов разными разработчиками с готовыми assurance cases на типовые для этих компонентов цели безопасности. Если при совмещении компонентов не возникает новых свойств, влияющих на нарушение гарантий, то такая система автоматически получает унаследованные от компонентов гарантии безопасности.
Для этого ввели три специальных свойства:
Компонуемость (composability) — условие, при котором компоненты могут быть составлены без ущерба для их индивидуальных свойств. Это важнейшее свойство, предоставляемое ядром разделения (или платформой MILS). Компоненты А и В могут выполняться изолированно, и ни один из них не влияет на работу другого.
Композиционность (compositionality) — условие, при котором компоненты могут быть составлены таким образом, чтобы создавать новые свойства композиции из их индивидуальных свойств. Композиционность представляет собой способность соединять два компонента таким образом, чтобы их поведение конструктивно комбинировалось для создания нового поведения.
Аддитивность (или аддитивная композиционность) (additivity) — особый вид композиционности, при котором «дополнение» отдельных, но различных свойств компонентов сохраняется в композиции наряду с их общими свойствами. Эта концепция необходима для обеспечения составления платформы MILS из основных компонентов MILS.
Ключевые моменты лекции 4 /
Верификация MILS системы
Проверка системы MILS состоит из четырех частей:
обоснование взаимного невлияния доменов (non-interference assurance),
обоснование локальных политик (local policies assurance),
обоснование безопасности архитектуры политики (policy architecture assurance),
обоснование свойства композиционности (compositionality)
☑️ Обоснование невлияния доменов проводится для компонентов, обеспечивающих совместное использование ресурсов, таких как ядра разделения, файловые системы с разделением доступа по доменам и коммуникационные системы с разделением доступа.
☑️ Обоснование локальных политик проводится для гарантии того, что отдельные доверенные домены корректно реализуют локальные политики, к примеру, для разграничение доступа к файлам и т.п.
☑️ Обоснование безопасности архитектуры политики дает гарантию того, что домены при совместном использовании ресурсов согласно архитектуре политики не выходят из множества безопасных состояний.
☑️ Отдельные домены в контексте архитектуры политик обеспечивают свойство композиционности для соблюдения требуемой общесистемной политики.
Эти четыре пункта по отдельности позволяют строить систему с некоторым количеством доверенных компонентов и возможным вовлечением недоверенных компонентов. Это возможно, так как перечисленные гарантии исключают влияние недоверенных компонентов на безопасность (в том числе, через нераспространение отказов в системе).
Верификация MILS системы
Проверка системы MILS состоит из четырех частей:
обоснование взаимного невлияния доменов (non-interference assurance),
обоснование локальных политик (local policies assurance),
обоснование безопасности архитектуры политики (policy architecture assurance),
обоснование свойства композиционности (compositionality)
☑️ Обоснование невлияния доменов проводится для компонентов, обеспечивающих совместное использование ресурсов, таких как ядра разделения, файловые системы с разделением доступа по доменам и коммуникационные системы с разделением доступа.
☑️ Обоснование локальных политик проводится для гарантии того, что отдельные доверенные домены корректно реализуют локальные политики, к примеру, для разграничение доступа к файлам и т.п.
☑️ Обоснование безопасности архитектуры политики дает гарантию того, что домены при совместном использовании ресурсов согласно архитектуре политики не выходят из множества безопасных состояний.
☑️ Отдельные домены в контексте архитектуры политик обеспечивают свойство композиционности для соблюдения требуемой общесистемной политики.
Эти четыре пункта по отдельности позволяют строить систему с некоторым количеством доверенных компонентов и возможным вовлечением недоверенных компонентов. Это возможно, так как перечисленные гарантии исключают влияние недоверенных компонентов на безопасность (в том числе, через нераспространение отказов в системе).
CSB - Part4.pdf
2.7 MB
Слайды к лекции 4 и место для обратной связи и вопросов
Вчера у нас было интересное обсуждение под конец лекции. Если политика безопасности «перекручена» до предела и не позволяет системе работать, может ли на это как-то повлиять архитектура? Другими словами, можно ли найти архитектуру системы, которая будет обеспечивать равновесие между безопасностью и прочими характеристиками?
В целом – конечно. Для этого хороший проектировщик и рассматривает цели безопасности совместно с целями системы на ранних этапах. Но откуда тогда берутся перекосы в ту или иную сторону, если есть техники для такого рода проектирования?
Считается, что решения людей исходят из чего-то рационального. Однако опыт указывает на то, что анализ полезности вариантов в большой степени попадают под когнитивные искажения, и поэтому совершают нелогичные поступки. В том числе и очень умные проектировщики и программисты.
Будем вводить в волшебные миры формальных методик людей, и они как обычно все там порушат. Попробуем восстановить.
Последняя лекция курса сегодня в 11 утра ☺️
В целом – конечно. Для этого хороший проектировщик и рассматривает цели безопасности совместно с целями системы на ранних этапах. Но откуда тогда берутся перекосы в ту или иную сторону, если есть техники для такого рода проектирования?
Считается, что решения людей исходят из чего-то рационального. Однако опыт указывает на то, что анализ полезности вариантов в большой степени попадают под когнитивные искажения, и поэтому совершают нелогичные поступки. В том числе и очень умные проектировщики и программисты.
Будем вводить в волшебные миры формальных методик людей, и они как обычно все там порушат. Попробуем восстановить.
Последняя лекция курса сегодня в 11 утра ☺️
Всем еще раз привет!
Мы закончили тренинг. Сегодня выложу материалы пятой лекции.
Огромная просьба к коллегам, к тем, кто присоединился офлайн или слушал через тимз, заполнить форму обратной связи. Если письмо с формой не пришло, а жгуче хочется написать пожелания - напишите, я скину ссылку.
И всем большое спасибо! Мне было интересно с вами на этой неделе, надеюсь и вы не скучали 😊
Мы закончили тренинг. Сегодня выложу материалы пятой лекции.
Огромная просьба к коллегам, к тем, кто присоединился офлайн или слушал через тимз, заполнить форму обратной связи. Если письмо с формой не пришло, а жгуче хочется написать пожелания - напишите, я скину ссылку.
И всем большое спасибо! Мне было интересно с вами на этой неделе, надеюсь и вы не скучали 😊
👍13🔥3
Ключевые моменты лекции 5 /
Принципы безопасности
До сих пор мы уделяли много внимания методическому подходу, но не говорили про эвристики. А это важно, учитывая, что чаще всего методы – это переработанные и формализованные lessons learned, то есть те самые эвристики.
В компьютерной безопасности выделяют 8 основных эвристик (иногда больше, иногда меньше), именно эти эвристики были сформулированы почти 50 лет назад Зальцером и Шредером, до сих пор они не утратили актуальность.
Это:
✔️Принцип простоты (Economy of mechanism): механизм должен быть настолько простым, насколько это возможно.
Важно не обманываться: системы систем могут казаться простыми, их скрытая сложность может либо быть спрятана в их сложных элементах, либо быть эмерджентной, то есть проявляться при взаимодействии элементов. Приведем в пример MILS: достаточно ясная модель архитектуры может включать в себя достаточно сложную реализацию отдельных доменов. Но, помимо этого, организация взаимодействия доменов на прикладном уровне влечет эмерджентную сложность. Ядро разделения превращает отдельный хост фактически в распределенную систему (сеть), а значит, поверх простых IPC между узлами этой системы нам потребуется стек протоколов. Это не обязательно TCP/IP – это может быть RPC фреймворк, которые как известно, всегда достаточно сложны (на заре MILS были исследования, можно ли успешно совместить ее, например, с CORBA). Это проблема, и она требует хорошего инженерного решения через декомпозицию и дальнейшее упрощение.
✔️Принцип безопасных умолчаний (Fail-safe defaults): решения о доступе должны приниматься на основе явных разрешений, а не на основе запретов.
✔️Принцип полноты перекрытия (complete mediation): каждый доступ к каждому контролируемому объекту должен проверяться. Применяется как «в пространстве», так и «во времени». Здесь можно напомнить про полноту спецификаций (верификация требований) и адекватность системы ее спецификации (валидация системы относительно верифицированных требований).
✔️Принцип открытого дизайна (open design): безопасность системы не должна базироваться на сокрытии деталей ее реализации. Можно сформулировать по-другому: раскрытие любых деталей реализации, кроме ключей и паролей, не должно влиять на степень безопасности системы.
Это работает в любую сторону: вопреки распространенному мнению, раскрытие деталей реализации в том числе через опенсорс не повышает безопасность системы или кода. Раскрытие кода может повышать доверие, но только в том случае, если способы контрибьютить в код контролируются (инициативы типа прозрачности).
✔️Принцип разделения привилегий (Separation of privilege) или разделения обязанностей: где возможно, принятие решения о доступе или о выполнении операции должно базироваться на двух факторах доверия вместо одного. Это могут быть два пользователя, независимо подтверждающие операцию, либо другие факторы, имеющие независимые факторы доверия.
Вопрос – больше независимых факторов – больше доверия? В целом да, но трудно реализовать много независимых факторов и раздельных каналов связи для доставки информации о них для авторизации.
✔️Принцип наименьших привилегий (Least privilege): каждый процесс или пользователь должен обладать наименьшими привилегиями для выполнения рабочих обязанностей. Иногда проблемой является недостаточная гранулярность привилегий и прав для выполнения принципа.
✔️Принцип наименьших разделяемых механизмов (Least common mechanism): следует минимизировать механизмы, от работы которых зависит один пользователь и работа которых определяется другими пользователями. Тут речь идет о снижении зависимостей и взаимного влияния, т.е. о том, что системы должны быть слабосвязанными.
✔️Принцип психологической приемлемости (psychological acceptability): Механизм безопасности не должен провоцировать собственное отключение (а в идеале, должен быть спроектирован так, чтобы «подталкивать» пользователя использовать его).
Принципы безопасности
До сих пор мы уделяли много внимания методическому подходу, но не говорили про эвристики. А это важно, учитывая, что чаще всего методы – это переработанные и формализованные lessons learned, то есть те самые эвристики.
В компьютерной безопасности выделяют 8 основных эвристик (иногда больше, иногда меньше), именно эти эвристики были сформулированы почти 50 лет назад Зальцером и Шредером, до сих пор они не утратили актуальность.
Это:
✔️Принцип простоты (Economy of mechanism): механизм должен быть настолько простым, насколько это возможно.
Важно не обманываться: системы систем могут казаться простыми, их скрытая сложность может либо быть спрятана в их сложных элементах, либо быть эмерджентной, то есть проявляться при взаимодействии элементов. Приведем в пример MILS: достаточно ясная модель архитектуры может включать в себя достаточно сложную реализацию отдельных доменов. Но, помимо этого, организация взаимодействия доменов на прикладном уровне влечет эмерджентную сложность. Ядро разделения превращает отдельный хост фактически в распределенную систему (сеть), а значит, поверх простых IPC между узлами этой системы нам потребуется стек протоколов. Это не обязательно TCP/IP – это может быть RPC фреймворк, которые как известно, всегда достаточно сложны (на заре MILS были исследования, можно ли успешно совместить ее, например, с CORBA). Это проблема, и она требует хорошего инженерного решения через декомпозицию и дальнейшее упрощение.
✔️Принцип безопасных умолчаний (Fail-safe defaults): решения о доступе должны приниматься на основе явных разрешений, а не на основе запретов.
✔️Принцип полноты перекрытия (complete mediation): каждый доступ к каждому контролируемому объекту должен проверяться. Применяется как «в пространстве», так и «во времени». Здесь можно напомнить про полноту спецификаций (верификация требований) и адекватность системы ее спецификации (валидация системы относительно верифицированных требований).
✔️Принцип открытого дизайна (open design): безопасность системы не должна базироваться на сокрытии деталей ее реализации. Можно сформулировать по-другому: раскрытие любых деталей реализации, кроме ключей и паролей, не должно влиять на степень безопасности системы.
Это работает в любую сторону: вопреки распространенному мнению, раскрытие деталей реализации в том числе через опенсорс не повышает безопасность системы или кода. Раскрытие кода может повышать доверие, но только в том случае, если способы контрибьютить в код контролируются (инициативы типа прозрачности).
✔️Принцип разделения привилегий (Separation of privilege) или разделения обязанностей: где возможно, принятие решения о доступе или о выполнении операции должно базироваться на двух факторах доверия вместо одного. Это могут быть два пользователя, независимо подтверждающие операцию, либо другие факторы, имеющие независимые факторы доверия.
Вопрос – больше независимых факторов – больше доверия? В целом да, но трудно реализовать много независимых факторов и раздельных каналов связи для доставки информации о них для авторизации.
✔️Принцип наименьших привилегий (Least privilege): каждый процесс или пользователь должен обладать наименьшими привилегиями для выполнения рабочих обязанностей. Иногда проблемой является недостаточная гранулярность привилегий и прав для выполнения принципа.
✔️Принцип наименьших разделяемых механизмов (Least common mechanism): следует минимизировать механизмы, от работы которых зависит один пользователь и работа которых определяется другими пользователями. Тут речь идет о снижении зависимостей и взаимного влияния, т.е. о том, что системы должны быть слабосвязанными.
✔️Принцип психологической приемлемости (psychological acceptability): Механизм безопасности не должен провоцировать собственное отключение (а в идеале, должен быть спроектирован так, чтобы «подталкивать» пользователя использовать его).
👍1
Ключевые моменты лекции 5 /
Кооперационные методы и конфликты интересов
Принципы безопасности применяются не только к реализации механизмов безопасности, но и к реализации процессов безопасной разработки. При этом совершенно не важен тип цикла разработки: как правило, тип ЖЦ разработки определяется другими нефункциональными требованиями и требованиями области разработки (например, автомобильная область требует V-цикла).
В целом, принципы безопасности можно применять для разрешения противоречий и простых конфликтов интересов при организации разработки ПО. Однако в практике обеспечения безопасности, особенно сейчас, когда риски не везде до конца ясны и нормативная база (в особенности для некритической инфраструктуры не определена) встречаются сложные конфликты интересов, разрешение которых лежит в области бизнеса или назначения.
В особенности это относится к анализу интересов, мотивов и побуждений стейкхолдеров. Оценка рисков, связанных с атаками, у разных участников отличается, при этом безопасность для бизнеса определенных игроков может быть как отрицательным стимулом (увеличение времени выхода на рынок для продукта из-за необходимости реализовать требования безопасности), так и положительным (безопасный продукт — это еще и конкурентное преимущество с точки зрения маркетинга). В идеале выбор мер и средств обеспечения безопасности должен быть решением весьма сложной задачи оптимизации ресурсов компании, отвечать интересам бизнеса в условиях внешних и внутренних ограничений.
Основной проблемой разработки стратегии защиты от киберугроз на этапе анализа бизнеса или назначения является то обстоятельство, что чаще всего безопасность воспринимается бизнесом как предмет беспокойства и статья затрат.
Именно поэтому обеспечение необходимых аспектов кибербезопасности и защиты от угроз часто становится коллективной «игрой в труса».
Так, производители продуктов для автоматизации технологического процесса до сих пор пытаются переложить ответственность за обеспечение безопасности своих продуктов на клиентов, утверждая, что их продукт должен быть использован в изолированной (от интернета, от офисной сети и т.д.) среде. При этом они упорно игнорируют объективную реальность, в которой большинство предприятий в погоне за увеличением эффективности своей работы оказываются не в состоянии эти требования выполнить.
С другой стороны, мы нередко слышим от представителей предприятий различных отраслей, что они не могут (или не хотят) применить те или иные меры (установить патч ОС, например) и средства безопасности (установить антивирус) к своим системам промышленной автоматизации (например, рабочему месту оператора) без подтверждения со стороны производителя продукта. Таким образом представители предприятий стремятся хотя бы частично переложить ответственность за принятие решений по обеспечению безопасности на производителей используемых ими продуктов.
Поиск баланса бизнес-стимулов в случае безопасности приводит к стратегии «балансирования на грани». Чтобы удержать равновесие, каждая из сторон — производители определенных видов оборудования, программного обеспечения, системные интеграторы, поставщики услуг, посредники, владельцы предприятий — ищут оптимальный набор мер безопасности и пытаются не выйти за рамки бюджета.
Кооперационные методы и конфликты интересов
Принципы безопасности применяются не только к реализации механизмов безопасности, но и к реализации процессов безопасной разработки. При этом совершенно не важен тип цикла разработки: как правило, тип ЖЦ разработки определяется другими нефункциональными требованиями и требованиями области разработки (например, автомобильная область требует V-цикла).
В целом, принципы безопасности можно применять для разрешения противоречий и простых конфликтов интересов при организации разработки ПО. Однако в практике обеспечения безопасности, особенно сейчас, когда риски не везде до конца ясны и нормативная база (в особенности для некритической инфраструктуры не определена) встречаются сложные конфликты интересов, разрешение которых лежит в области бизнеса или назначения.
В особенности это относится к анализу интересов, мотивов и побуждений стейкхолдеров. Оценка рисков, связанных с атаками, у разных участников отличается, при этом безопасность для бизнеса определенных игроков может быть как отрицательным стимулом (увеличение времени выхода на рынок для продукта из-за необходимости реализовать требования безопасности), так и положительным (безопасный продукт — это еще и конкурентное преимущество с точки зрения маркетинга). В идеале выбор мер и средств обеспечения безопасности должен быть решением весьма сложной задачи оптимизации ресурсов компании, отвечать интересам бизнеса в условиях внешних и внутренних ограничений.
Основной проблемой разработки стратегии защиты от киберугроз на этапе анализа бизнеса или назначения является то обстоятельство, что чаще всего безопасность воспринимается бизнесом как предмет беспокойства и статья затрат.
Именно поэтому обеспечение необходимых аспектов кибербезопасности и защиты от угроз часто становится коллективной «игрой в труса».
Так, производители продуктов для автоматизации технологического процесса до сих пор пытаются переложить ответственность за обеспечение безопасности своих продуктов на клиентов, утверждая, что их продукт должен быть использован в изолированной (от интернета, от офисной сети и т.д.) среде. При этом они упорно игнорируют объективную реальность, в которой большинство предприятий в погоне за увеличением эффективности своей работы оказываются не в состоянии эти требования выполнить.
С другой стороны, мы нередко слышим от представителей предприятий различных отраслей, что они не могут (или не хотят) применить те или иные меры (установить патч ОС, например) и средства безопасности (установить антивирус) к своим системам промышленной автоматизации (например, рабочему месту оператора) без подтверждения со стороны производителя продукта. Таким образом представители предприятий стремятся хотя бы частично переложить ответственность за принятие решений по обеспечению безопасности на производителей используемых ими продуктов.
Поиск баланса бизнес-стимулов в случае безопасности приводит к стратегии «балансирования на грани». Чтобы удержать равновесие, каждая из сторон — производители определенных видов оборудования, программного обеспечения, системные интеграторы, поставщики услуг, посредники, владельцы предприятий — ищут оптимальный набор мер безопасности и пытаются не выйти за рамки бюджета.
Ключевые моменты лекции 5 /
Модель зрелости безопасности. Назначение
Оценка необходимости обеспечения безопасности у различных организаций будет всегда разной. Даже при схожих рисках последствия возможных инцидентов для одних компаний могут быть более значимыми, чем для других.
Правильный выбор мер и средств обеспечения безопасности не всегда очевиден. Более того, локальные бизнес-цели и мотивированные ими решения по безопасности, принимаемые различными участниками процесса обеспечения безопасности (например, производителем и потребителем продуктов и сервисов) могут оказаться не только разными, но и несовместными. Возможно самым неприятным аспектом этой ситуации является непонимание одной из сторон ограничений, потребностей и аргументов принятия решений по безопасности другой стороны.
Цель модели зрелости безопасности интернета вещей (IIC IoT Security Maturity Model, IoT SMM) — обеспечить соответствие способов защиты от киберугроз реальным бизнес-потребностям. Задача — сформировать конкретное описание состояния «достаточной безопасности» для системы, помочь ответственным за безопасность этой системы лицам сфокусироваться на наилучших способах достижения этого состояния и определить соответствующие меры защиты.
Архитектура выбора — это систематизация вариантов, которая подталкивает людей к выбору способа действий и к началу этих действий, то есть в нашем случае — к созданию более безопасной системы. Архитектурой выбора и ядром модели зрелости безопасности интернета вещей является иерархия практик обеспечения безопасности (security practices). Практикой обеспечения безопасности, к примеру, является реализация контроля доступа, защита данных при их хранении и передаче или управление обновлениями безопасности.
Системный подход к выбору вариантов защиты поддерживается группированием практик по ожидаемому эффекту от их применения. Чтобы максимально упростить процесс выбора, на самом верхнем уровне группы практик объединяются в домены.
Модель зрелости безопасности. Назначение
Оценка необходимости обеспечения безопасности у различных организаций будет всегда разной. Даже при схожих рисках последствия возможных инцидентов для одних компаний могут быть более значимыми, чем для других.
Правильный выбор мер и средств обеспечения безопасности не всегда очевиден. Более того, локальные бизнес-цели и мотивированные ими решения по безопасности, принимаемые различными участниками процесса обеспечения безопасности (например, производителем и потребителем продуктов и сервисов) могут оказаться не только разными, но и несовместными. Возможно самым неприятным аспектом этой ситуации является непонимание одной из сторон ограничений, потребностей и аргументов принятия решений по безопасности другой стороны.
Цель модели зрелости безопасности интернета вещей (IIC IoT Security Maturity Model, IoT SMM) — обеспечить соответствие способов защиты от киберугроз реальным бизнес-потребностям. Задача — сформировать конкретное описание состояния «достаточной безопасности» для системы, помочь ответственным за безопасность этой системы лицам сфокусироваться на наилучших способах достижения этого состояния и определить соответствующие меры защиты.
Архитектура выбора — это систематизация вариантов, которая подталкивает людей к выбору способа действий и к началу этих действий, то есть в нашем случае — к созданию более безопасной системы. Архитектурой выбора и ядром модели зрелости безопасности интернета вещей является иерархия практик обеспечения безопасности (security practices). Практикой обеспечения безопасности, к примеру, является реализация контроля доступа, защита данных при их хранении и передаче или управление обновлениями безопасности.
Системный подход к выбору вариантов защиты поддерживается группированием практик по ожидаемому эффекту от их применения. Чтобы максимально упростить процесс выбора, на самом верхнем уровне группы практик объединяются в домены.
Три верхнеуровневых домена безопасности включают:
1. управление безопасностью и организационные меры (Governance),
2. обеспечение безопасности в силу конструкции (by design, Enablement)
3. укрепление безопасности (Hardening).
Приоритет того или иного домена перед другим для вендора определяется потребностями бизнеса и особенностями системы (но первые — прежде вторых).
На втором уровне каждый из доменов делится на три поддомена, которые классифицируют практики безопасности в соответствии с проблемой, на решение которой они нацелены. И наконец, каждый поддомен ссылается на 2 практики, каждая из которых решает некоторую задачу. Пример: управление безопасностью (Governance) включает поддомен управления зависимостями (supply chain and dependencies management), который, в свою очередь, состоит из обеспечения безопасности цепочки поставок (supply chain risk management) и управления зависимостями от подрядчиков, поставщиков сервисов и других сторонних субъектов (third party dependencies management)
1. управление безопасностью и организационные меры (Governance),
2. обеспечение безопасности в силу конструкции (by design, Enablement)
3. укрепление безопасности (Hardening).
Приоритет того или иного домена перед другим для вендора определяется потребностями бизнеса и особенностями системы (но первые — прежде вторых).
На втором уровне каждый из доменов делится на три поддомена, которые классифицируют практики безопасности в соответствии с проблемой, на решение которой они нацелены. И наконец, каждый поддомен ссылается на 2 практики, каждая из которых решает некоторую задачу. Пример: управление безопасностью (Governance) включает поддомен управления зависимостями (supply chain and dependencies management), который, в свою очередь, состоит из обеспечения безопасности цепочки поставок (supply chain risk management) и управления зависимостями от подрядчиков, поставщиков сервисов и других сторонних субъектов (third party dependencies management)