Добрый день. Меня зовут Екатерина Рудина, и я создала этот канал в поддержку курса теоретических основ компьютерной безопасности, который я придумала для моих коллег. Курс для внутреннего использования, тут будут только открытые материалы для свободного распространения. Велкам!
🔥13
Итак, книги!
Matt Bishop. Computer Security: Art and Science
Базовая книга по теории компьютерной безопасности. Включает описание формальных моделей безопасности и моделей контроля доступа. Лучшее место, если вы ищете объяснений, почему нельзя просто сформулировать политики доступа, доказать для них раз и навсегда формальное свойство безопасности (через утечку прав) и жить с формально безопасной системой. Описания новых технологий защиты тут не найдете, но базу получите крепкую, освоив хотя бы первые 100 страниц.
Заменяет множество отечественных изданий.
Matt Bishop. Computer Security: Art and Science
Базовая книга по теории компьютерной безопасности. Включает описание формальных моделей безопасности и моделей контроля доступа. Лучшее место, если вы ищете объяснений, почему нельзя просто сформулировать политики доступа, доказать для них раз и навсегда формальное свойство безопасности (через утечку прав) и жить с формально безопасной системой. Описания новых технологий защиты тут не найдете, но базу получите крепкую, освоив хотя бы первые 100 страниц.
Заменяет множество отечественных изданий.
👍3
Shon Harris. All In One CISSP Exam Guide
Почти без комментариев: крепкий Body of Knowledge, отдельный домен для Security Architecture and Engineering, ограниченный, но достаточный перечень моделей безопасности. Хорошее справочное руководство, рекомендую даже если совсем не собираетесь сдавать на сертификацию.
Почти без комментариев: крепкий Body of Knowledge, отдельный домен для Security Architecture and Engineering, ограниченный, но достаточный перечень моделей безопасности. Хорошее справочное руководство, рекомендую даже если совсем не собираетесь сдавать на сертификацию.
Книги по системной инженерии
INCOSE Systems Engineering Handbook. A Guide for System Life Cycle Processes and Activities
Профессиональное сообщество International Council on Systems Engineering (INCOSE) – знак качества. Книга с упором на определение и описание процессов жизненного цикла систем. Широко известна как SE Handbook. Является основой для многих международных стандартов. Предпоследнее издание обычно доступно в pdf
INCOSE Systems Engineering Handbook. A Guide for System Life Cycle Processes and Activities
Профессиональное сообщество International Council on Systems Engineering (INCOSE) – знак качества. Книга с упором на определение и описание процессов жизненного цикла систем. Широко известна как SE Handbook. Является основой для многих международных стандартов. Предпоследнее издание обычно доступно в pdf
👍1
M.Maier, E.Rechtin The Art of Systems Architecting
В сравнении с предыдущей книгой, дает более общий обзор процесса создания архитектуры систем, описывает ту часть, которая про «искусство» и как она стыкуется с наукой. Хороша для получения цельной картины вопросов, связанных с созданием сложных систем. Доступна тут
В сравнении с предыдущей книгой, дает более общий обзор процесса создания архитектуры систем, описывает ту часть, которая про «искусство» и как она стыкуется с наукой. Хороша для получения цельной картины вопросов, связанных с созданием сложных систем. Доступна тут
🔥1
SYSTEMS ARCHITECTING AND SOFTWARE INTEGRATION
Подстрочник семинара E.Rechtin, блестящий текст по системной инженерии. В дополнение в The Art of System Architecting.
Подстрочник семинара E.Rechtin, блестящий текст по системной инженерии. В дополнение в The Art of System Architecting.
Наконец, стандарты. ISO/IEC/IEEE 42010:2011 Systems and software engineering — Architecture description Международный стандарт на описание архитектур, согласующийся с упомянутыми книгами и используемый как основа при создании других международных стандартов. С ним вместе и на основе SE Handbook - ISO/IEC/IEEE 15288:2015 "Systems and software engineering - System life cycle processes" (наверняка вы его знаете)
Если хочется только на русском языке, то есть выжимка в виде адаптированного международного стандарта ГОСТ 57100 и ГОСТ 57193 тут
https://docs.cntd.ru/document/1200139542
https://docs.cntd.ru/document/1200141163
Если хочется только на русском языке, то есть выжимка в виде адаптированного международного стандарта ГОСТ 57100 и ГОСТ 57193 тут
https://docs.cntd.ru/document/1200139542
https://docs.cntd.ru/document/1200141163
Ключевые моменты лекции 1 /
Безопасность, доверие и благонадежность
Понятие доверия имеет сразу несколько интерпретаций. Первая и самая очевидная: необходимость и возможность полагаться в силу различных факторов на поведение аппаратного или программного обеспечения, или людей, то есть доверять им безусловно. В число таких факторов доверия для оборудования и ПО могут входить репутация поставщика, его происхождение и вероятная незаинтересованность в намеренной компрометации инфраструктуры. Для людей это моральная и материальная ответственность, ответственность в силу законодательства, достаточность квалификации и знаний для выполнения служебных обязанностей. По сути, такое доверие (с англ. trust) базируется на предположениях и является по большей части вынужденным.
В другой интерпретации, доверие к системе – это определенная и, как правило, достаточная степень уверенности в том, что система работает, как и ожидалось, в отношении набора характеристик. Эти характеристики включают в себя функциональную безопасность, защищенность от атак, конфиденциальность и целостность данных, надежность и отказоустойчивость системы перед лицом внешних воздействий, ошибок человека, системных сбоев и атак. Степень уверенности достигается через выполнение процедур по оценке доверия.
Доверие в этой интерпретации (trustworthiness) – это благонадежность системы. Оно не является безусловным и должно демонстрироваться процедурами оценки доверия, основанными на ряде предположений.
Безопасность, доверие и благонадежность
Понятие доверия имеет сразу несколько интерпретаций. Первая и самая очевидная: необходимость и возможность полагаться в силу различных факторов на поведение аппаратного или программного обеспечения, или людей, то есть доверять им безусловно. В число таких факторов доверия для оборудования и ПО могут входить репутация поставщика, его происхождение и вероятная незаинтересованность в намеренной компрометации инфраструктуры. Для людей это моральная и материальная ответственность, ответственность в силу законодательства, достаточность квалификации и знаний для выполнения служебных обязанностей. По сути, такое доверие (с англ. trust) базируется на предположениях и является по большей части вынужденным.
В другой интерпретации, доверие к системе – это определенная и, как правило, достаточная степень уверенности в том, что система работает, как и ожидалось, в отношении набора характеристик. Эти характеристики включают в себя функциональную безопасность, защищенность от атак, конфиденциальность и целостность данных, надежность и отказоустойчивость системы перед лицом внешних воздействий, ошибок человека, системных сбоев и атак. Степень уверенности достигается через выполнение процедур по оценке доверия.
Доверие в этой интерпретации (trustworthiness) – это благонадежность системы. Оно не является безусловным и должно демонстрироваться процедурами оценки доверия, основанными на ряде предположений.
Ключевые моменты лекции 1 /
Аспекты безопасности, свойства, -ilities
Однако какие аспекты мы можем оценивать, и самое главное, что именно предполагает оценка? Это не только известная триада CIA, в нее давно «не помещается» все многообразие аспектов, которые требуют от доверенной системы. В интерпретации Industrial IoT Consortium, доверие включает аспекты компьютерной безопасности, функциональной безопасности, надежности, устойчивости и приватности. Определения можно найти в публично доступных документах IIC. Раз, два, три
Интерпретировав эти понятия, мы понимаем, что это еще не предел для так называемых “-ilities” (свойств, условно относимых к качеству системы). Их катастрофически много. Предлагается следующий bullshit детектор: 1. Свойство должно быть доступно для интерпретации и моделирования с внятным объяснением того, что имеется в виду под этим свойством 2. Интерпретация должна проходить неформальную валидацию – все заинтересованные стороны должны понимать его одинаково 3. Должен существовать способ проверки или измерения свойства (верифицируемость свойства). Пример – демонстрация испытаний стула в IKEA.
Свойства также разделяются на два типа: свойство «формальной безопасности» (safety) - «можно показать, что при определенных условиях некоторое нежелательное событие не произойдет» и свойство «формальной живости» (liveness) - «можно показать, что при определенных условиях некоторое желательное событие обязательно произойдет». Тип свойства важен для определения того, является ли оно верифицируемым, и как его можно верифицировать (или нельзя). Из пятерки свойств IIC trustworthiness safety, security и reliability – это свойства «формальной безопасности», а resilience и privacy – свойства «формальной живости» (как минимум в том виде, в котором их определяют документы IIC, при другом определении это может поменяться).
Аспекты безопасности, свойства, -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). На протяжении курса мы будем неоднократно возвращаться к этой классификации.
Нормативный подход заключается в применении к системе, ее элементам и процессам ЖЦ обязательных требований, включая требования законодательства, государственных и отраслевых регуляторов, но не ограничиваясь этими требованиями.
Методический подход заключается в применении к системе, ее элементам и процессам ЖЦ классического дедуктивного метода проектирования («сверху вниз») – моделей, шаблонов проектирования и разработки, а также формально определенных алгоритмов взаимодействия и протоколов, обеспечивающих передачу данных, контроль и управление, обладающие заданными свойствами.
Кооперационный подход заключается в совместной деятельности заинтересованных лиц – участников процессов ЖЦ системы, целью этой деятельности является учет всех интересов участников при реализации требований к системе. В том числе, кооперационный подход включает реализацию участниками требований к безопасной разработке системы, но не ограничивается им.
Эвристический подход заключается в применении системе принципов и «лучших практик», представляющих результаты извлеченных уроков из предыдущего опыта проектирования (подход «снизу вверх»).
Подходы разделены не строго, могут эволюционировать между собой и видоизменяться, будучи использованы вместе.
Подходы к проектированию в системной инженерии
Чтобы перейти от абстрактных аспектов и их проверки к целям безопасности, давайте обсудим подходы, применяемые в проектировании (а создание целей безопасности из неструктурированного описания – это именно проектирование). Рехтин и Мэйер определяют 4 подхода: нормативный (normative), методический (rational, method-based), кооперационный (participative), эвристический (heuristic). На протяжении курса мы будем неоднократно возвращаться к этой классификации.
Нормативный подход заключается в применении к системе, ее элементам и процессам ЖЦ обязательных требований, включая требования законодательства, государственных и отраслевых регуляторов, но не ограничиваясь этими требованиями.
Методический подход заключается в применении к системе, ее элементам и процессам ЖЦ классического дедуктивного метода проектирования («сверху вниз») – моделей, шаблонов проектирования и разработки, а также формально определенных алгоритмов взаимодействия и протоколов, обеспечивающих передачу данных, контроль и управление, обладающие заданными свойствами.
Кооперационный подход заключается в совместной деятельности заинтересованных лиц – участников процессов ЖЦ системы, целью этой деятельности является учет всех интересов участников при реализации требований к системе. В том числе, кооперационный подход включает реализацию участниками требований к безопасной разработке системы, но не ограничивается им.
Эвристический подход заключается в применении системе принципов и «лучших практик», представляющих результаты извлеченных уроков из предыдущего опыта проектирования (подход «снизу вверх»).
Подходы разделены не строго, могут эволюционировать между собой и видоизменяться, будучи использованы вместе.
👍1
Ключевые моменты лекции 1 /
Цели безопасности. Предположения безопасности
Исходя из всего вышесказанного, нам нужно научиться формулировать цели безопасности, обладающие следующими предпочтительными свойствами: 1. Сформулированы в объективной и конкретной манере 2. Желательно, чтобы они были описаны как инвариант, то есть для формулировок нужно использовать описательные выражения (например, описывающие, а не предписывающие эвристики).
Эти цели должны быть определены, исходя из неконсистентного, вероятно неполного перечня интересов, мотивов и побуждений к безопасности, действующего для заинтересованных сторон. При создании системы нередки ситуации конфликта интересов, отсутствия реальной мотивации к трате ресурсов на безопасность и т.п. Поэтому применяем доступные нам методы: лучше всего на первых этапах работают эвристики, неплохо подходит нормативная база, можно использовать кооперационные методы (брейнсторм, совместная работа). Методический подход к анализу конфликта интересов и анализу стратегий должен работать, но на фактически не используется: непрактично. В определении целей безопасности может быть несколько итераций уточнения.
Предположения безопасности как правило, касаются ряда определенных факторов, должны быть сформулированы однозначно и четко. Невысказанные предположения представляют собой риски безопасности или создают почву для рисков.
Цели безопасности. Предположения безопасности
Исходя из всего вышесказанного, нам нужно научиться формулировать цели безопасности, обладающие следующими предпочтительными свойствами: 1. Сформулированы в объективной и конкретной манере 2. Желательно, чтобы они были описаны как инвариант, то есть для формулировок нужно использовать описательные выражения (например, описывающие, а не предписывающие эвристики).
Эти цели должны быть определены, исходя из неконсистентного, вероятно неполного перечня интересов, мотивов и побуждений к безопасности, действующего для заинтересованных сторон. При создании системы нередки ситуации конфликта интересов, отсутствия реальной мотивации к трате ресурсов на безопасность и т.п. Поэтому применяем доступные нам методы: лучше всего на первых этапах работают эвристики, неплохо подходит нормативная база, можно использовать кооперационные методы (брейнсторм, совместная работа). Методический подход к анализу конфликта интересов и анализу стратегий должен работать, но на фактически не используется: непрактично. В определении целей безопасности может быть несколько итераций уточнения.
Предположения безопасности как правило, касаются ряда определенных факторов, должны быть сформулированы однозначно и четко. Невысказанные предположения представляют собой риски безопасности или создают почву для рисков.
👍1
Имея достаточно деталей о технологии и предполагаемой реализации системы, можно построить модель угроз для системы в целом и ее элементов. Цели безопасности нельзя «заужать», так как дополнительные ограничения еще поступят от реализации их механизмами безопасности. Методы гарантии безопасности применимы к механизмам, исходя из реализации этих механизмов. Тут хорошую службу сослужит правильная архитектура системы: доказательство безопасности может упроститься. Со своей стороны, отдельным интересом заинтересованных сторон может быть получение определенного уровня гарантий.
А вот включение требований к гарантиям безопасности в перечень целей безопасности не является хорошей практикой: лучше, чтобы цели безопасности были объектом валидации. Требование гарантий «внутри» списка целей приведет к «самоприменению» требования и неразрешимости задачи.
Также тонкий момент заключается в том, что, если заинтересованные лица выставляют требования непосредственно к механизмам безопасности в обход формулирования целей, это может привести к неадекватной или неполной реализации безопасности, перерасходу средств, так называемому «театру безопасности» и другим неприятностям. Поэтому формулирование (проектирование) перечня целей и предположений безопасности является обязательным этапом в создании систем secure by design.
А вот включение требований к гарантиям безопасности в перечень целей безопасности не является хорошей практикой: лучше, чтобы цели безопасности были объектом валидации. Требование гарантий «внутри» списка целей приведет к «самоприменению» требования и неразрешимости задачи.
Также тонкий момент заключается в том, что, если заинтересованные лица выставляют требования непосредственно к механизмам безопасности в обход формулирования целей, это может привести к неадекватной или неполной реализации безопасности, перерасходу средств, так называемому «театру безопасности» и другим неприятностям. Поэтому формулирование (проектирование) перечня целей и предположений безопасности является обязательным этапом в создании систем secure by design.