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)
Ключевые моменты лекции 5 /
Измерение зрелости безопасности
Чтобы устанавливать приоритеты и сравнивать реализацию мер безопасности, требуется шкала измерения. Оценивать эффективность метода защиты от киберугроз, перенесенного из классической IT-безопасности в среду интернета вещей, можно по двум параметрам. Первый — насколько сам подход хорошо реализован, насколько систематизировано его применение, так называемая полнота реализации (comprehensiveness). Этот параметр хорошо иллюстрируется на примере оценки безопасности веб-приложений, к которой можно подходить с разной степенью усердия. Можно описать угрозы в общем — кража учетных данных, перебор пароля, DDoS атака. Это будет первый, минимальный уровень полноты (minimum). Можно проанализировать сценарии работы приложения для детализации модели угроз — второй уровень (ad hoc). Можно при детализации использовать систематизацию атак OWASP TOP 10, можно добавить к этому еще метод STRIDE, в этом случае уровень полноты — третий, упорядоченный (consistent). В конце концов, можно организовать целый формальный процесс периодической переоценки угроз, включающей все перечисленные методы — максимальный четвертый уровень (formalized).
Очень важно отметить, что полнота (comprehensiveness) — это еще не зрелость. Банковское веб-приложение требует наиболее полного подхода, а веб-приложение для сравнения текущего времени в разных часовых поясах может ограничиться рассмотрением сценариев работы с ним для выявления потенциальных проблем. Зрелый подход для приложения работы со временем будет недостаточным для банковского приложения. То есть зрелость, в отличие от полноты, — величина относительная.
Второй параметр, который имеет значение именно для интернета вещей, — насколько специфичным (scope) должен быть подход с учетом требований индустрии или даже конкретной системы. Оценка угроз для устройств, создаваемых, к примеру, в автомобильной индустрии (и многих других), должна фокусироваться на предотвращении в первую очередь физической опасности для жизни и здоровья людей, для окружающей среды. Значимые угрозы для медицинского устройства — те, что способны вызвать изменение специальных параметров его работы, иногда даже незначительное (например, дозировка лекарства для пациента). Смещение фокуса на специфичные проблемы (scope) для реализации конкретной практики безопасности также напрямую определяет ее зрелость, если мы говорим об интернете вещей. Здесь мы рассматриваем три варианта: общая неспецифичная реализация (General), специфичная для индустрии (Industry) и специфичная для системы (System). Последний вариант важен, поскольку сейчас появляется много решений на стыке индустрий, или просто специального назначения, из тех, что мы не видели раньше, — взять хотя бы «умный дом».
Измерение зрелости безопасности
Чтобы устанавливать приоритеты и сравнивать реализацию мер безопасности, требуется шкала измерения. Оценивать эффективность метода защиты от киберугроз, перенесенного из классической IT-безопасности в среду интернета вещей, можно по двум параметрам. Первый — насколько сам подход хорошо реализован, насколько систематизировано его применение, так называемая полнота реализации (comprehensiveness). Этот параметр хорошо иллюстрируется на примере оценки безопасности веб-приложений, к которой можно подходить с разной степенью усердия. Можно описать угрозы в общем — кража учетных данных, перебор пароля, DDoS атака. Это будет первый, минимальный уровень полноты (minimum). Можно проанализировать сценарии работы приложения для детализации модели угроз — второй уровень (ad hoc). Можно при детализации использовать систематизацию атак OWASP TOP 10, можно добавить к этому еще метод STRIDE, в этом случае уровень полноты — третий, упорядоченный (consistent). В конце концов, можно организовать целый формальный процесс периодической переоценки угроз, включающей все перечисленные методы — максимальный четвертый уровень (formalized).
Очень важно отметить, что полнота (comprehensiveness) — это еще не зрелость. Банковское веб-приложение требует наиболее полного подхода, а веб-приложение для сравнения текущего времени в разных часовых поясах может ограничиться рассмотрением сценариев работы с ним для выявления потенциальных проблем. Зрелый подход для приложения работы со временем будет недостаточным для банковского приложения. То есть зрелость, в отличие от полноты, — величина относительная.
Второй параметр, который имеет значение именно для интернета вещей, — насколько специфичным (scope) должен быть подход с учетом требований индустрии или даже конкретной системы. Оценка угроз для устройств, создаваемых, к примеру, в автомобильной индустрии (и многих других), должна фокусироваться на предотвращении в первую очередь физической опасности для жизни и здоровья людей, для окружающей среды. Значимые угрозы для медицинского устройства — те, что способны вызвать изменение специальных параметров его работы, иногда даже незначительное (например, дозировка лекарства для пациента). Смещение фокуса на специфичные проблемы (scope) для реализации конкретной практики безопасности также напрямую определяет ее зрелость, если мы говорим об интернете вещей. Здесь мы рассматриваем три варианта: общая неспецифичная реализация (General), специфичная для индустрии (Industry) и специфичная для системы (System). Последний вариант важен, поскольку сейчас появляется много решений на стыке индустрий, или просто специального назначения, из тех, что мы не видели раньше, — взять хотя бы «умный дом».
Ключевые моменты лекции 5 /
Связь модели зрелости безопасности с кооперационными практиками. Nudge
Итоговая эффективность системы защиты определяется управленческими решениями, при принятии которых постоянно требуется делать выбор: какие средства использовать, насколько радикально подходить к изменению состава компонентов системы, на какие мероприятия тратить ресурсы. Этот выбор чрезвычайно сложен.
Важны два фактора: упрощение процесса планирования и организация согласований, поскольку видение приоритетов безопасности различается для заинтересованных в этой безопасности сторон. Структурирование практик позволяет упростить процесс планирования и принятия решений. Налаженный механизм общения между техническим персоналом и владельцами рисков со стороны бизнеса помогает согласованно подойти к этому планированию. Представители технической стороны смогут трезво обрисовать задачи и назначения практик безопасности, которые могут быть реализованы, их потенциальную эффективность относительно разных видов риска. Представители бизнеса, используя этот опыт, — приоритизировать меры обеспечения безопасности, поставить цели и построить кратковременные и долговременные планы по их достижению.
Эта задача долговременного планирования — экономическая, схожая с инвестированием, или выбором программы страхования, или любым другим упражнением с конфликтом стимулов. Современный подход к решению таких задач предусматривает использование так называемого nudge (подталкивания) — построения архитектуры выбора, поддерживающей эффективное принятие решений в определенной сфере. IoT SMM с установленным процессом формирования целевого профиля зрелости безопасности — это фреймворк для архитектуры выбора (или попросту nudge) в сфере информационной безопасности интернета вещей, который позволяет сделать первый шаг (а также второй, третий и так далее) в задаче построения безопасной системы, будь то крупное производство или фитнес-браслет.
Таким образом, использование модели зрелости позволяет оптимизировать постановку задачи безопасности интернета вещей, то есть определить уровень «достаточной безопасности», провести оценку и планирование объема работ, которые необходимо провести для её достижения с требуемой детализацией, начиная с уровня доменов безопасности вплоть до отдельных практик.
Основные публикации Industrial IoT Consortium, относящиеся к модели зелости безопасности можено найти тут https://www.iiconsortium.org/smm.htm
Статью, которую я подробно цитировала выше, можно целиком прочитать по ссылке
Также можно ее прочитать или отправить кому-то на английском
Связь модели зрелости безопасности с кооперационными практиками. Nudge
Итоговая эффективность системы защиты определяется управленческими решениями, при принятии которых постоянно требуется делать выбор: какие средства использовать, насколько радикально подходить к изменению состава компонентов системы, на какие мероприятия тратить ресурсы. Этот выбор чрезвычайно сложен.
Важны два фактора: упрощение процесса планирования и организация согласований, поскольку видение приоритетов безопасности различается для заинтересованных в этой безопасности сторон. Структурирование практик позволяет упростить процесс планирования и принятия решений. Налаженный механизм общения между техническим персоналом и владельцами рисков со стороны бизнеса помогает согласованно подойти к этому планированию. Представители технической стороны смогут трезво обрисовать задачи и назначения практик безопасности, которые могут быть реализованы, их потенциальную эффективность относительно разных видов риска. Представители бизнеса, используя этот опыт, — приоритизировать меры обеспечения безопасности, поставить цели и построить кратковременные и долговременные планы по их достижению.
Эта задача долговременного планирования — экономическая, схожая с инвестированием, или выбором программы страхования, или любым другим упражнением с конфликтом стимулов. Современный подход к решению таких задач предусматривает использование так называемого nudge (подталкивания) — построения архитектуры выбора, поддерживающей эффективное принятие решений в определенной сфере. IoT SMM с установленным процессом формирования целевого профиля зрелости безопасности — это фреймворк для архитектуры выбора (или попросту nudge) в сфере информационной безопасности интернета вещей, который позволяет сделать первый шаг (а также второй, третий и так далее) в задаче построения безопасной системы, будь то крупное производство или фитнес-браслет.
Таким образом, использование модели зрелости позволяет оптимизировать постановку задачи безопасности интернета вещей, то есть определить уровень «достаточной безопасности», провести оценку и планирование объема работ, которые необходимо провести для её достижения с требуемой детализацией, начиная с уровня доменов безопасности вплоть до отдельных практик.
Основные публикации Industrial IoT Consortium, относящиеся к модели зелости безопасности можено найти тут https://www.iiconsortium.org/smm.htm
Статью, которую я подробно цитировала выше, можно целиком прочитать по ссылке
Также можно ее прочитать или отправить кому-то на английском
Industry IoT Consortium
Security Maturity Model - Industry IoT Consortium
Security Maturity Model: Practitioner’s Guide Home Pages IIC SMM Publications IoT Security Maturity Model: Augmented Reality Profile IoT Security Maturity […]
KOS-MILS 2022.pdf
1.4 MB
Всем привет!
Почти неделя, как мы расстались, несу вам немного добра. Сегодня добро состоит из слайдов про MILS (в контексте рассказа про KOS) на русском языке.
Ну, Вселенная очень попросила 😊
Почти неделя, как мы расстались, несу вам немного добра. Сегодня добро состоит из слайдов про MILS (в контексте рассказа про KOS) на русском языке.
Ну, Вселенная очень попросила 😊
👍7🔥1
Media is too big
VIEW IN TELEGRAM
Ну вот настало то самое мифическое "после майских".
Буду потихоньку подкармливать канал кусочками, которым не нашлось место в курсе.
Сегодня говорим про разделение обязанностей (separation of duties) и что это такое в ИБ.
Для тех, кто не любит слушать, а любит читать, выложу подстрочник со ссылками.
Комментариям и вопросам - велкам, как обычно
Буду потихоньку подкармливать канал кусочками, которым не нашлось место в курсе.
Сегодня говорим про разделение обязанностей (separation of duties) и что это такое в ИБ.
Для тех, кто не любит слушать, а любит читать, выложу подстрочник со ссылками.
Комментариям и вопросам - велкам, как обычно
👍9
Разделение обязанностей (separation of duties) – чуть ли не самая туманная тема в ИБ.
Во-первых, терминологическая путаница вокруг нее несусветная. Separation of duties или segregation of duties? А чем отличаются separation of privileges, separation of functions, separation of tasks?
Во-вторых, практически нет дизайн-паттернов для реализации и особенно для распознавания, когда разделение обязанностей требуется, сплошные примеры и кейсы.
И в-третьих, то есть даже в-нулевых, что такое эти самые обязанности (duties)? В теории ИБ больше нигде не используется этот термин. Права есть – обязанностей нет 😊
При этом конструктивные решения на основе разделения обязанностей очень эффективно работают в плане предотвращения фрода и разного рода намеренных нарушений безопасности. Это происходит из-за разделения и ослабления факторов вынужденного доверия (trust). То есть фактически через разделение обязанностей мы можем ослабить влияние ненадежных предположений безопасности. Это нужно делать всегда, когда только получается.
Поэтому если удается распознать ситуацию, позволяющую ввести разделение обязанностей, то это обязательно нужно сделать.
Давайте разберемся.
Во-первых, терминологическая путаница вокруг нее несусветная. Separation of duties или segregation of duties? А чем отличаются separation of privileges, separation of functions, separation of tasks?
Во-вторых, практически нет дизайн-паттернов для реализации и особенно для распознавания, когда разделение обязанностей требуется, сплошные примеры и кейсы.
И в-третьих, то есть даже в-нулевых, что такое эти самые обязанности (duties)? В теории ИБ больше нигде не используется этот термин. Права есть – обязанностей нет 😊
При этом конструктивные решения на основе разделения обязанностей очень эффективно работают в плане предотвращения фрода и разного рода намеренных нарушений безопасности. Это происходит из-за разделения и ослабления факторов вынужденного доверия (trust). То есть фактически через разделение обязанностей мы можем ослабить влияние ненадежных предположений безопасности. Это нужно делать всегда, когда только получается.
Поэтому если удается распознать ситуацию, позволяющую ввести разделение обязанностей, то это обязательно нужно сделать.
Давайте разберемся.
Принцип разделения обязанностей «вырос» не из области обеспечения безопасности бумажных-важных документов, а из коммерческих областей, чувствительных к фроду. Отсюда, видимо, нетипичное для ИБ слово – обязанности. И отсюда же частый пример разделения обязанностей: необходимость двух подписей на платежном поручении для осуществления платежа.
Зальцер и Шредер формулируют его как принцип разделения привилегий: где возможно, принятие решения о доступе или о выполнении операции должно базироваться на двух факторах доверия вместо одного.
Принцип разделения привилегий и принцип разделения обязанностей – это одно и то же. Называйте как нравится, хотя аббревиатура SoD фактически всем понятна, а SoP я как-то не встречала.
Паттерны реализации SoD следующие:
1️⃣ Последовательное разделение: выполнение двух или более действий в определенном порядке. К примеру: выполнение тестирования программного модуля, аппрув отчета о результатах тестирования, аппрув перехода к стадии релиза.
2️⃣ Разделение по принципуводолаза "четыре глаза": два человека независимо выполняют одно действие или подтверждают факт его выполнения. Типичный пример – ревью кода.
3️⃣Пространственное разделение: действие раздельно выполняется в двух различных пространственных локациях. Типичнейшее – разделение продакшн окружения от среды разработки.
4️⃣Многофакторное разделение, основанное на нескольких факторах подтверждения, ну тут я думаю, все понятно.
С паттернами распознавания все сложнее. Чаще всего для распознавания ситуаций, когда требуется SoD, нужно искать «слабые» предположения безопасности и усиливать их:
▶️ вторым фактором доверия
▶️ разделением среды (то есть – разделением доменов, например в MILS системе)
▶️ добавлением альтернативных средств мониторинга безопасности (хостовой + сетевой мониторинг – это тот же SoD)
▶️ внедрением протоколов, основанных на разделении секретов (secret sharing)
и т.д.
Разделение секретов кстати не стоит в ряду «разделение обязанностей – привилегий – функций…». Это просто криптографический прием, позволяющий распределить данные между несколькими субъектами так, чтобы восстановить их можно было только собравшись вместе или каким-то определенным минимальным коллективом. Почитать можно у Шнайера в «Прикладной криптографии», ну или википедию посмотреть.
Зальцер и Шредер формулируют его как принцип разделения привилегий: где возможно, принятие решения о доступе или о выполнении операции должно базироваться на двух факторах доверия вместо одного.
Принцип разделения привилегий и принцип разделения обязанностей – это одно и то же. Называйте как нравится, хотя аббревиатура SoD фактически всем понятна, а SoP я как-то не встречала.
Паттерны реализации SoD следующие:
1️⃣ Последовательное разделение: выполнение двух или более действий в определенном порядке. К примеру: выполнение тестирования программного модуля, аппрув отчета о результатах тестирования, аппрув перехода к стадии релиза.
2️⃣ Разделение по принципу
3️⃣Пространственное разделение: действие раздельно выполняется в двух различных пространственных локациях. Типичнейшее – разделение продакшн окружения от среды разработки.
4️⃣Многофакторное разделение, основанное на нескольких факторах подтверждения, ну тут я думаю, все понятно.
С паттернами распознавания все сложнее. Чаще всего для распознавания ситуаций, когда требуется SoD, нужно искать «слабые» предположения безопасности и усиливать их:
▶️ вторым фактором доверия
▶️ разделением среды (то есть – разделением доменов, например в MILS системе)
▶️ добавлением альтернативных средств мониторинга безопасности (хостовой + сетевой мониторинг – это тот же SoD)
▶️ внедрением протоколов, основанных на разделении секретов (secret sharing)
и т.д.
Разделение секретов кстати не стоит в ряду «разделение обязанностей – привилегий – функций…». Это просто криптографический прием, позволяющий распределить данные между несколькими субъектами так, чтобы восстановить их можно было только собравшись вместе или каким-то определенным минимальным коллективом. Почитать можно у Шнайера в «Прикладной криптографии», ну или википедию посмотреть.
Telegram
Computer security basics
Ключевые моменты лекции 5 /
Принципы безопасности
До сих пор мы уделяли много внимания методическому подходу, но не говорили про эвристики. А это важно, учитывая, что чаще всего методы – это переработанные и формализованные lessons learned, то есть те самые…
Принципы безопасности
До сих пор мы уделяли много внимания методическому подходу, но не говорили про эвристики. А это важно, учитывая, что чаще всего методы – это переработанные и формализованные lessons learned, то есть те самые…
Что же касается «separation of functions», то часто этот термин встречается как прямой синоним SoD или разделения привилегий. Но вот это уже я совсем не считаю правильным, как минимум в контексте ИБ. Во-первых, это терминологически неаккуратно: separation of functions, как и separation of tasks относится к любым функциям (задачам), не только к требующим каких-то особенных привилегий. А значит их точно так же можно отнести к необходимости, например, функционального деления ПО на модули, например так, чтобы каждому пользователю были сопоставлены только необходимые функции (задачи). А это уже реализация принципа минимальных привилегий. Выходит путаница.
Я знаю только про одно «официальное» использование принципов разделения обязанностей и разделения функций: в рамках модели Липнера, описывающей разработку ПО. Вот так их описание дается в книжке Мэтта Бишопа:
«Принцип разделения обязанностей гласит, что, если для выполнения критической функции требуется два или более шагов, эти шаги должны выполнять как минимум два разных человека. Перемещение программы из системы разработки в продакшн является примером критической функции. Предположим, что один из разработчиков приложений сделал неверное предположение при разработке программы. Часть процедуры установки заключается в том, чтобы установщик удостоверил, что программа работает «правильно», то есть в соответствии с требованиями. Ошибка с большей вероятностью будет обнаружена, если установщиком является другой человек (или группа людей), а не разработчик. Точно так же, если разработчик хочет испортить данные в продакшн, внедрив трояна, то либо установщик, проверяющий корректность работы, не должен обнаружить троянский код, либо он должен быть в сговоре с разработчиком. (примечание – это снижает вероятность успеха атаки)
Разделение функций определяется так: один человек не должен иметь возможность выполнять разные задачи (роли) в рамках одной критической функции. Разработчики не разрабатывают новые программы в продакшн окружении из-за потенциальной угрозы реальным рабочим данным. Точно так же разработчики не обрабатывают реальные данные в окружении разработки во избежание утечки этих данных. В зависимости от конфиденциальности данных разработчики и тестировщики могут получать очищенные (sanitized) реальные данные. Кроме того, среда разработки должна быть максимально похожа на продакшн».
Тут, собственно, речь о том, что нельзя пытаться «обойти» разделение обязанностей между ролями, назначив две разные роли одному и тому же человеку/субъекту. Отсюда остается всего один шаг до ролевой модели, в которой разделение обязанностей определено куда более формально и логично. Об этом – в следующей серии)
Я знаю только про одно «официальное» использование принципов разделения обязанностей и разделения функций: в рамках модели Липнера, описывающей разработку ПО. Вот так их описание дается в книжке Мэтта Бишопа:
«Принцип разделения обязанностей гласит, что, если для выполнения критической функции требуется два или более шагов, эти шаги должны выполнять как минимум два разных человека. Перемещение программы из системы разработки в продакшн является примером критической функции. Предположим, что один из разработчиков приложений сделал неверное предположение при разработке программы. Часть процедуры установки заключается в том, чтобы установщик удостоверил, что программа работает «правильно», то есть в соответствии с требованиями. Ошибка с большей вероятностью будет обнаружена, если установщиком является другой человек (или группа людей), а не разработчик. Точно так же, если разработчик хочет испортить данные в продакшн, внедрив трояна, то либо установщик, проверяющий корректность работы, не должен обнаружить троянский код, либо он должен быть в сговоре с разработчиком. (примечание – это снижает вероятность успеха атаки)
Разделение функций определяется так: один человек не должен иметь возможность выполнять разные задачи (роли) в рамках одной критической функции. Разработчики не разрабатывают новые программы в продакшн окружении из-за потенциальной угрозы реальным рабочим данным. Точно так же разработчики не обрабатывают реальные данные в окружении разработки во избежание утечки этих данных. В зависимости от конфиденциальности данных разработчики и тестировщики могут получать очищенные (sanitized) реальные данные. Кроме того, среда разработки должна быть максимально похожа на продакшн».
Тут, собственно, речь о том, что нельзя пытаться «обойти» разделение обязанностей между ролями, назначив две разные роли одному и тому же человеку/субъекту. Отсюда остается всего один шаг до ролевой модели, в которой разделение обязанностей определено куда более формально и логично. Об этом – в следующей серии)
👍4
Привет, а вот опрос.
Интересно ли вам видеть короткие видеолекции или объяснения в канале (как вчера), или достаточно текста?
Интересно ли вам видеть короткие видеолекции или объяснения в канале (как вчера), или достаточно текста?
Anonymous Poll
47%
Видео (аудио) нужно, мне слушать удобнее чем читать
53%
Хватит текста и иногда слайдов
А вот давайте про читовые модели угроз поговорим?
Недавно в руки попал документ на ревью, long story short, содержащий в числе прочего перечень угроз для устройств IoT. Один нюанс, при ближайшем рассмотрении в перечне оказались не угрозы, а уязвимости.
Вообще описание уязвимости под угрозу замаскировать легко. Например, «пароль по умолчанию» становится «использованием пароля по умолчанию», race condition становится «атакой одновременного доступа», захардкоженный пароль или сертификат становится «раскрытием или угадыванием информации».
Продолжение 👇
Недавно в руки попал документ на ревью, long story short, содержащий в числе прочего перечень угроз для устройств IoT. Один нюанс, при ближайшем рассмотрении в перечне оказались не угрозы, а уязвимости.
Вообще описание уязвимости под угрозу замаскировать легко. Например, «пароль по умолчанию» становится «использованием пароля по умолчанию», race condition становится «атакой одновременного доступа», захардкоженный пароль или сертификат становится «раскрытием или угадыванием информации».
Продолжение 👇