Добрый день. Меня зовут Екатерина Рудина, и я создала этот канал в поддержку курса теоретических основ компьютерной безопасности, который я придумала для моих коллег. Курс для внутреннего использования, тут будут только открытые материалы для свободного распространения. Велкам!
🔥14
Итак, книги!
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, ограниченный, но достаточный перечень моделей безопасности. Хорошее справочное руководство, рекомендую даже если совсем не собираетесь сдавать на сертификацию.
👍1
Книги по системной инженерии
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, при другом определении это может поменяться).