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

Поэтому "архитектурный подход к безопасности" – это перевод, который не в полной мере отражает security by design, так как в этом by design большая доля инженерного подхода. Например, мы идем от целей безопасности для системы, при необходимости декомпозируем их, поддерживаем отслеживаемость до требований, затем в обратную сторону верифицируем, валидируем решение относительно целей.

Требование к тому, чтобы эти процессы выполнялись вместе с созданием правильной архитектуры системы (ее внутренней организации) является неотъемлемой частью подхода security by design. Так что термина «архитектура» нам явно недостаточно, нужен более объемлющий термин.

3/3
Теперь почему "конструктивная безопасность". Термин этот в действительности взят из строительного стандарта. Он означает именно то, что нам нужно: здание не только должно иметь правильную архитектуру для того, чтобы не разрушиться и быть устойчивым к внешним факторам.
Мы недавно всем ICS CERT-ом были на Чиркейской ГЭС. С архитектурной точки зрения это выдающееся сооружение. Однако создание всего надежного и безопасного комплекса ГЭС полагалось и на качество бетонных блоков, и на технологии бетонирования, и на уникальные технологии проходки и укрепления горной породы, боюсь, не смогу перечислить все. Больше описаний с картинками можно посмотреть тут

При строительстве предъявляются требования к материалам (у нас это качество кода), к инструментам (кран не должен упасть на здание в процессе строительства), к технологиям (приготовление строительных растворов, выдерживание технологических интервалов).. Безопасность инженерных коммуникаций имеет существенное значение для конструктивной безопасности. Например, пожаробезопасность зависит от вентиляции, это часть конструктивной безопасности. А у нас безопасность данных, к примеру, зависит от коммуникационных протоколов.
Так что "security by design" действительно более точно переводится как "конструктивная безопасность", а не "безопасность в силу архитектуры"

Согласны?

Канал набирает потихоньку людей. Кто-то знает меня лично, кто-то просто пришел по ссылке.
Видео выше - о команде, в которой я работаю, набираюсь знаний (чтобы потом ими делиться) уже почти 8 лет.

Вдогонку со вчерашнему посту, вдруг кому будет интересно: Евгений Гончаров (тот, что на видео) завтра расскажет, что год 23й нам возможно готовит в смысле угроз для промышленных инфраструктур.
Регистрация тут
От себя добавлю, что обновлять и возможно даже строить инфраструктуры заново нам предстоит в самое ближайшее время, а, значит, будут еще курсы, документы, посты. Вернусь с апдейтами скоро.

Доброе утро перед длинными выходными! Полезная информация: мой коллега Сергей Соболев проводит мини-курсы онлайн, посвященные разработке кибериммунных решений. В канале https://www.tgoop.com/learning_cyberimmunity, который есть информация по теме, записи прошедших курсов и анонсы новых наборов. Следующая группа стартует во вторник, 28 февраля. Обучение (пока) бесплатное. Осталось примерно 5 мест.

Хорошая новость - на прошлой неделе были введены в действие два знаковых национальных стандарта (ПНСТ) на системы с разделением доменов.

Стандарты разработаны в Лаборатории Касперского и приняты ТК 194 «Киберфизические системы».

Вот ссылки:
Информационные технологии. Интернет вещей. Системы с разделением доменов. Термины и определения

Информационные технологии. Интернет вещей. Системы с разделением доменов. Базовые компоненты

Далее будет серия постов с ответами на часто задаваемые вопросы.

FAQ по стандартам «Системы с разделением доменов»/1

Что такое системы с разделением доменов?
Системы с разделением доменов построены на основе архитектурного подхода с разделением доменов. Это стратегия построения систем, требующих функциональной и информационной безопасности с высокой степенью уверенности.
Разделение доменов означает декомпозицию системы на составные части (домены) с запретом на обмен данными между этими частями. Декомпозиция должна проводиться агрессивно, на низком уровне системы, при поддержке аппаратных технологий разделения среды (например, IOMMU). В основе системы лежит т.н. ядро разделения, ответственное за выполнение разделения и изоляцию доменов.
Разрешение на обмен информацией или сигналами между отдельными доменами выполняется явно и сопровождается анализом аспектов безопасности системы. Множество каналов разрешенного взаимодействия доменов составляет архитектуру политики взаимодействия в системе.

Зачем разрабатывались стандарты на системы с разделением доменов?
Лаборатория Касперского работает над вариантом системы с разделением доменов – операционной системой KasperskyOS. В ходе этой работы мы выяснили, что в отечественных документах любого рода (стандарты, методические документы) и даже в учебниках по безопасности отсутствуют нужные нам термины, определения и понятия, на которые можно было бы ссылаться при описании проектных архитектурных решений. Нужно было адаптировать термины и опыт из зарубежных документов. Во избежание расхождений в переводе и интерпретации понятий мы провели работу над национальными стандартами.