Три верхнеуровневых домена безопасности включают:
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). Последний вариант важен, поскольку сейчас появляется много решений на стыке индустрий, или просто специального назначения, из тех, что мы не видели раньше, — взять хотя бы «умный дом».

Ключевые моменты лекции 5 /
Связь модели зрелости безопасности с кооперационными практиками. Nudge

Итоговая эффективность системы защиты определяется управленческими решениями, при принятии которых постоянно требуется делать выбор: какие средства использовать, насколько радикально подходить к изменению состава компонентов системы, на какие мероприятия тратить ресурсы. Этот выбор чрезвычайно сложен.

Важны два фактора: упрощение процесса планирования и организация согласований, поскольку видение приоритетов безопасности различается для заинтересованных в этой безопасности сторон. Структурирование практик позволяет упростить процесс планирования и принятия решений. Налаженный механизм общения между техническим персоналом и владельцами рисков со стороны бизнеса помогает согласованно подойти к этому планированию. Представители технической стороны смогут трезво обрисовать задачи и назначения практик безопасности, которые могут быть реализованы, их потенциальную эффективность относительно разных видов риска. Представители бизнеса, используя этот опыт, — приоритизировать меры обеспечения безопасности, поставить цели и построить кратковременные и долговременные планы по их достижению.

Эта задача долговременного планирования — экономическая, схожая с инвестированием, или выбором программы страхования, или любым другим упражнением с конфликтом стимулов. Современный подход к решению таких задач предусматривает использование так называемого nudge (подталкивания) — построения архитектуры выбора, поддерживающей эффективное принятие решений в определенной сфере. IoT SMM с установленным процессом формирования целевого профиля зрелости безопасности — это фреймворк для архитектуры выбора (или попросту nudge) в сфере информационной безопасности интернета вещей, который позволяет сделать первый шаг (а также второй, третий и так далее) в задаче построения безопасной системы, будь то крупное производство или фитнес-браслет.

Таким образом, использование модели зрелости позволяет оптимизировать постановку задачи безопасности интернета вещей, то есть определить уровень «достаточной безопасности», провести оценку и планирование объема работ, которые необходимо провести для её достижения с требуемой детализацией, начиная с уровня доменов безопасности вплоть до отдельных практик.

Основные публикации Industrial IoT Consortium, относящиеся к модели зелости безопасности можено найти тут https://www.iiconsortium.org/smm.htm

Статью, которую я подробно цитировала выше, можно целиком прочитать по ссылке
Также можно ее прочитать или отправить кому-то на английском

Это было содержание пятой лекции. Я пожалуй оставлю этот канал живым и буду периодически возвращаться с интересным контентом.
А пока - хороших выходных!

Всем привет!
Почти неделя, как мы расстались, несу вам немного добра. Сегодня добро состоит из слайдов про MILS (в контексте рассказа про KOS) на русском языке.
Ну, Вселенная очень попросила 😊

Ну вот настало то самое мифическое "после майских".
Буду потихоньку подкармливать канал кусочками, которым не нашлось место в курсе.

Сегодня говорим про разделение обязанностей (separation of duties) и что это такое в ИБ.
Для тех, кто не любит слушать, а любит читать, выложу подстрочник со ссылками.

Комментариям и вопросам - велкам, как обычно

Разделение обязанностей (separation of duties) – чуть ли не самая туманная тема в ИБ.

Во-первых, терминологическая путаница вокруг нее несусветная. 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)
и т.д.
Разделение секретов кстати не стоит в ряду «разделение обязанностей – привилегий – функций…». Это просто криптографический прием, позволяющий распределить данные между несколькими субъектами так, чтобы восстановить их можно было только собравшись вместе или каким-то определенным минимальным коллективом. Почитать можно у Шнайера в «Прикладной криптографии», ну или википедию посмотреть.

Что же касается «separation of functions», то часто этот термин встречается как прямой синоним SoD или разделения привилегий. Но вот это уже я совсем не считаю правильным, как минимум в контексте ИБ. Во-первых, это терминологически неаккуратно: separation of functions, как и separation of tasks относится к любым функциям (задачам), не только к требующим каких-то особенных привилегий. А значит их точно так же можно отнести к необходимости, например, функционального деления ПО на модули, например так, чтобы каждому пользователю были сопоставлены только необходимые функции (задачи). А это уже реализация принципа минимальных привилегий. Выходит путаница.

Я знаю только про одно «официальное» использование принципов разделения обязанностей и разделения функций: в рамках модели Липнера, описывающей разработку ПО. Вот так их описание дается в книжке Мэтта Бишопа:
«Принцип разделения обязанностей гласит, что, если для выполнения критической функции требуется два или более шагов, эти шаги должны выполнять как минимум два разных человека. Перемещение программы из системы разработки в продакшн является примером критической функции. Предположим, что один из разработчиков приложений сделал неверное предположение при разработке программы. Часть процедуры установки заключается в том, чтобы установщик удостоверил, что программа работает «правильно», то есть в соответствии с требованиями. Ошибка с большей вероятностью будет обнаружена, если установщиком является другой человек (или группа людей), а не разработчик. Точно так же, если разработчик хочет испортить данные в продакшн, внедрив трояна, то либо установщик, проверяющий корректность работы, не должен обнаружить троянский код, либо он должен быть в сговоре с разработчиком. (примечание – это снижает вероятность успеха атаки)
Разделение функций определяется так: один человек не должен иметь возможность выполнять разные задачи (роли) в рамках одной критической функции. Разработчики не разрабатывают новые программы в продакшн окружении из-за потенциальной угрозы реальным рабочим данным. Точно так же разработчики не обрабатывают реальные данные в окружении разработки во избежание утечки этих данных. В зависимости от конфиденциальности данных разработчики и тестировщики могут получать очищенные (sanitized) реальные данные. Кроме того, среда разработки должна быть максимально похожа на продакшн».

Тут, собственно, речь о том, что нельзя пытаться «обойти» разделение обязанностей между ролями, назначив две разные роли одному и тому же человеку/субъекту. Отсюда остается всего один шаг до ролевой модели, в которой разделение обязанностей определено куда более формально и логично. Об этом – в следующей серии)

Всем привет!
Коллеги из ЛК, наш 10тичасовой курс порезали на съедобные кусочки и выложили на SF. Теперь его можно проходить официально и гордиться галочкой в профиле)
Ссылку ищите на интранете

А вот давайте про читовые модели угроз поговорим?

Недавно в руки попал документ на ревью, long story short, содержащий в числе прочего перечень угроз для устройств IoT. Один нюанс, при ближайшем рассмотрении в перечне оказались не угрозы, а уязвимости.
Вообще описание уязвимости под угрозу замаскировать легко. Например, «пароль по умолчанию» становится «использованием пароля по умолчанию», race condition становится «атакой одновременного доступа», захардкоженный пароль или сертификат становится «раскрытием или угадыванием информации».

Продолжение 👇

Польза от такой «модели угроз-уязвимостей» есть разве что до начала использования системы. Уязвимость == угроза для участников процесса разработки, с определенными оговорками. Обнаружение уязвимостей тормозит работу, заставляет менять код, добавлять функционал. Однако полноценной угрозой уязвимость станет только тогда, когда разработчика непосредственно за нее оштрафуют. Это может произойти из-за нарушения KPI, сдвигов срока релиза, придется проводить выплату по bug bounty и т.п. Вот тогда уязвимость полностью совпадает с угрозой с явно определенным ущербом.
Некоторые уязвимости могут продолжать оставаться «угрозами для разработчика» и после начала использования системы – но только в контексте необходимости патчей. Стоимость выпуска патча == угрозе для разработчика, стоимость раскатывания == угрозе для интегратора и т.п. Если же мы представим, что система с момента релиза обновления получать не будет по любой причине (увозится в тайгу, погружается на дно морское, производитель прекращает поддержку), то получается, что угрозы нет?
Для разработчика – действительно нет (если не считать репутацию). Он общение с системой закончил, нет тела – нет дела. А для владельца системы, пользователей, обслуживающий персонал, если таковой имеется, угроза есть (уязвимость-то есть), но ее описание почти не имеет смысла. Потому все, что их волнует – это не причины, а импакт угрозы, и как его дешевле предотвратить.
Если приводить аналогию, то лишь небольшое число людей занимаются изучением причин и многочисленных последствий тектоники литосферных плит. На самом деле никто не знает, почему происходят сейсмические сдвиги. При этом практически все боятся землетрясений и их разрушительных последствий в сейсмоактивных областях планеты.
Давайте предположим, что причина того, что литосфера Земли – пазл с плохо пригнанными краями – нам известна. Повлияет ли это на нашу оценку угроз сейсмоактивности? Конфигурация планеты уже релизнута и плохо поддается патчам – нужно справляться с последствиями, предотвращать катастрофическое течение событий. Причины катастрофы нужно понимать до той степени, в которой это помогает с ней справится.

Модель угроз, рассчитанная на систему в контексте ее использования, сфокусирована на последствиях угроз (тех, которые нарушают цели безопасности). Она может учитывать технические аспекты уязвимостей и групп уязвимостей, пока это важно для того, чтобы предотвратить угрозы или снизить их воздействие. Но она не должна их дублировать.

Всем привет! Смотрите какой стандарт вышел совсем недавно
Словарь доверия. Или доверенности. Или благонадежности. Как мы там определяли trustworthiness?🤔

✔️✔️Trustworthiness: ability to meet stakeholders’ expectations in a verifiable way.

Кратко и по делу. Уже ниже дается описание trustworthiness characteristics (те самые -ilities). И все они в этом стандарте имеют такие определения – лаконичные, конкретные.
А если не получается термин определить достаточно конкретно? Стоит пояснить контекст, и сразу все получится. Например, целостность определена два раза: для системы, и для данных:
✔️Integrity: <data> property whereby data have not been altered in an unauthorized manner since they were created, transmitted, or stored
✔️Integrity: <systems> property of accuracy (3.2.2) and completeness

Или надежность определена в контексте системы и в контексте характеристики кибербезопасности:
✔️Reliability: <cybersecurity> property of consistent intended behaviour and results
✔️Reliability: <system> ability of an item to perform as required, without failure, for a given time interval, under given conditions

Как думаете, круто придумали, или это читерство, и путаница в итоге выйдет?

PS Стандарт по ссылке конечно предлагается купить, но можно и воспользоваться «Preview», которое как раз для ИСО-шных стандартов по обыкновению содержит термины и определения. Когда речь идет о стандарте-словаре, это очень удачно, я считаю😊

Мегановость ☄️
Видеоматериалы с курса выложены в открытый доступ на платформе Stepik.
Мы поделились ими практически в полном объеме, с обсуждениями, острыми вопросами из зала и из чата. Жалею только что мы не писали общение во время кофе-брейков)
Жду на степике всех, кто не из ЛК или не имел возможности присоединиться к нам раньше!

Где найти практические примеры решений, построенных по принципу security by design aka конструктивная безопасность в реальном применении?🤔

Кажется, уж точно не в промышленной безопасности. Конечно, все знают, что АСУ ТП дырявые и, конечно, производители очень стараются их защитить.

Но зачем нам враги, когда у нас есть такие друзья, говорит аналитик, погруженный в изучение монолитных архитектур, прикидывающихся компонентными, протоколов аутентификации, проводящих вычисления только на стороне клиента и диковатых криптоалгоритмов, не защищающих, а раскрывающих пароли (подробности – в публикациях Kaspersky ICS CERT).

И даже если бы дела с безопасностью отдельных решений обстояли получше, сложные разнородные инфраструктуры всегда будут не до конца безопасными: особенности отдельных конфигураций, проблемы совместимости решений, необходимость доступности для гарантий safety не дают скучать.

Не обойтись без эшелонированной защиты, в первую очередь, без мониторинга безопасности и оперативного реагирования на инциденты.

К слову, о security by design: меня всегда восхищало изящество сетевых СОВ как решения для мониторинга. Прозрачная установка, невлияние на работу сети, невозможность атаковать саму СОВ напрямую - как будто специально придумано для промышленности. Но детали о работе процессов, подключенных устройств, содержимое шифрованного трафика и прочие нужности на уровне сети недоступны, тут работают endpoint агенты.

И совмещение данных для анализа, получаемых от обоих типов решения – та еще задачка, если мы хотим сохранить безопасность всего решения «by design». Именно в силу упомянутых достоинств.

Я слежу за Kaspersky OT Cybersecurity еще с рабочего названия TMS и полностью отдельно разрабатываемого «антивируса для SCADA». Мы привыкли различать KICS for Networks и KICS for Nodes. Больше не нужно: наши архитекторы собрали их единую платформу с кросс-продуктовыми сценариями для эффективной аналитики и расследования инцидентов в промышленных системах.

Самое время и место для правильных архитектурных решений. Как работает XDR платформа KICS, будут показывать завтра, 6 декабря в 11.00. Искренне рекомендую.

Меня часто спрашивают, почему я и мои коллеги переводим "security by design» как "конструктивная безопасность", а не как "безопасность в силу архитектуры".
Объяснение в трех частях

1/3
Дело в том, что слово «architecture» и слово «design» не являются синонимами. А дальше вопрос, можем ли мы переводить дизайн как архитектуру (коротко – нет).

Если длинно, то хорошо бы включить в термины "инженерный подход" - engineering.
Построение архитектуры системы (architecting) – это задача, решаемая индуктивным образом, а то время как при проектировании системы инженерными средствами (engineering) применяется подход от общего к частному, то есть дедуктивный.