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

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

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

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

Согласны?

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

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

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

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

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

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

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

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

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

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

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

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

Являются ли системы с разделением доменов конструктивно безопасными (secure by design)?
Подход с разделением доменов является методом создания архитектуры, который может применяться при создании конструктивно безопасных систем. В отрыве от других методов, он может не дать нужный результат, однако в комплексе мероприятий действительно эффективен.

Насколько новым является подход, есть ли соответствующий мировой опыт?
Впервые понятие ядра разделения (separation kernel) и соответствующей архитектуры системы описано в статье J.Rushby в 1981 году. Практический подход к созданию систем с разделением доменов активно исследуется и реализуется примерно с начала двухтысячных годов (подробнее я рассказывала здесь и здесь) и носит название MILS.

Почему стандарты разрабатывались для Интернета вещей, можно ли их применять еще где-то?
Идея разработки стандартов в контексте киберфизических систем и Интернета вещей связана с универсальностью подхода в отношении безопасности. Он способствует как информационной безопасности, так и функциональной, а это особенно важно для систем, которые «выходят в физический мир». Тем не менее, в чистом «информационном» окружении архитектура с разделением доменов для проектирования, реализации и сертификации безопасных систем работает не хуже.

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

Почему документы носят статус ПНСТ (предварительный национальный стандарт), а не ГОСТ?
Так как несколько человек уже спросили, расскажу, что значит «предварительный стандарт».
Согласно статье 2 162-ФЗ «О стандартизации», предварительный национальный стандарт (ПНСТ) - документ по стандартизации, который разработан участником или участниками работ по стандартизации, по результатам экспертизы в техническом комитете по стандартизации или проектном техническом комитете по стандартизации утвержден федеральным органом исполнительной власти в сфере стандартизации и в котором для всеобщего применения устанавливаются общие характеристики объекта стандартизации, а также правила и общие принципы в отношении объекта стандартизации на ограниченный срок в целях накопления опыта в процессе применения предварительного национального стандарта для возможной последующей разработки на его основе национального стандарта.
Так как большая часть понятий, терминов и определений, вводимых в наших документах, является новой для отечественной практики, накопление опыта действительно необходимо. Работу над документами мы не прекращаем, и надеемся на активное участие сообщества в ней.
При этом условия применения ПНСТ точно такие же, как у ГОСТ (статья 26 упомянутого ФЗ) – «Документы национальной системы стандартизации (ГОСТ, ПНСТ, правила стандартизации, рекомендации по стандартизации, информационно-технические справочники) применяются на добровольной основе одинаковым образом и в равной мере независимо от страны и (или) места происхождения продукции (товаров, работ, услуг), если иное не установлено законодательством Российской Федерации».
Так что это просто статус, обозначение того, что стандартизация не стоит на месте.

Жду еще вопросы в комментариях!

В некоторых отраслях системы с разделением доменов существовали примерно всегда. Например, в автомобильной. Вмешательство в бортовую сеть, объединяющую электронные блоки управления, из инфотейнмент окружения всегда было затруднительно. Если помните - в исследовании Миллера и Валасека 2014 года основная техническая трудность отправки джипа чероки в кювет удаленно заключалась как раз в обходе этой изоляции.
Однако все меняется, и к сожалению, не всегда в лучшую сторону. Электроника автомобилей становится сложнее и все уязвимее к намеренным атакам.
Вебинар, который я советую не пропускать: мои коллеги по ICS CERT Сергей Ануфриенко и Александр Козлов расскажут о киберугрозах современным автомобилям
Сама пойду)

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

Истории будет 4 и рассказывать буду понемногу, по мере подготовки подстрочника

История первая, о криптографии. Как строить, строить и наконец ничего не построить

В начале 2021 года была официально опубликована информация об уязвимостях различной степени критичности (от 3.1 до 7.1) в ПЛК Modicon M100/M200/M221 производства Schneider Electric. Уязвимости связаны с недостатками реализации криптографических функций защиты данных.
Эти и подобные контроллеры используются для базовой машинной автоматизации в автоматизации упаковки, погрузочно-разгрузочных работах, в том числе в логистических системах (доставке), переработке материалов, в промышленной роботизации. Конкретно контроллеры этих линеек работают на базе изначально небезопасного протокола Modbus over TCP. Аутентификация инженера и дальнейший обмен данными, к примеру, при переконфигурации контроллера требуют защиты. Если нарушитель получил доступ к промышленной сети, то его несанкционированный доступ к контроллеру или MitM атака c подделкой данных может привести к непредсказуемым последствиям, в том числе физическому ущербу.

Так ли уж защищает от подобных атак спроектированная инженерами Schneider Electric криптография?

На самом деле нет: при реализации защиты были сделаны детские ошибки.
Во-первых, собственный алгоритм для генерации общего «секрета» (ключа), несколько похожий на алгоритм Диффи-Хеллмана, но отличающийся в деталях (замечу, что этот алгоритм генерации секрета не является устойчивым к MitM атаке)
Во-вторых, длина того самого секрета – всего 4 байта! Пространство перебора очень небольшое, да и сложность задачи дискретного логарифмирования в таких порядках невысока
В-третьих, для генерации случайных данных использовалось текущее время, а это абсолютно плохая практика, так как числа получаются предсказуемыми.
В-четвертых, в трафике смешивались шифрованные и нешифрованные данные, это всегда облегчает криптоанализ.
Ну, и в-пятых, никакой криптоанализ и не требовался, точнее, требовался в минимальном объеме. Дело в том, что для шифрования передаваемых данных на общем «секрете» использовалось «исключающее или» (XOR) с этим ключом. Для Modbus трафика с предсказуемыми, часто нулевыми заполнениями, это позволяет в некоторых участках дампа трафика попросту наблюдать ключ в открытом виде (XOR нулевых байтов и ключа даст сам ключ).
Давайте вспомним, что разработка каких-то новых функций в ПО известного оборудования – довольно дорогостоящая история. Кто-то обосновал и спроектировал эту «защиту», описал требования, был проведен цикл разработки, включая контроль качества, успешно прошел релиз. Эффект для безопасности – околонулевой. Издержки на выпуск обновления, коммуникацию, поддержку репутации.
А стоило всего лишь привлечь кого-то, кто не пропускал лекции по основам криптографии в универе

Ссылки на оригинальные источники в блоге Kaspersky ICS CERT

История вторая, о доверии технологиям. Двое из ИБ-ларца

Что такое технология? Совокупность идей и их технического воплощения для достижения определенной цели. В ИБ отрасли техническое воплощение идеи само по себе должно быть безупречно с точки зрения безопасности, с двух точек зрения.
Первая точка зрения – отсутствие уязвимостей. Атака на защитный механизм делает этот механизм бесполезным.
Вторая точка зрения – отсутствие скрытых возможностей. Потому что у того, кто вас защищает, есть все возможности обратить свою силу против вас же. А значит, защитному механизму нужно доверять.
Давайте еще вспомним, что уязвимости, при определенной степен паранойи, можно рассматривать ка скрытые возможности ПО.

А теперь с этих точек зрения посмотрим на историю с возможностями/уязвимостями ПО, которое устанавливается при использовании USB-токенов ИБ-гиганта Gemalto. Заметим, что подключаемое устройство не хранит в себе ни вредоносного, ни уязвимого легитимного кода, и его подключение служит лишь триггером для установки полнофункционального легитимного бэкдора из более чем легитимного источника.
Исследуемый продукт – это комплекс, включающий USB-носитель и набор драйверов и прикладного ПО, устанавливаемого на компьютер для работы с лицензионными ключами. USB-токен надо подключать к персональному компьютеру или серверу, на котором ПО требуется лицензия. В этом менеджере лицензий исследователи Kaspersky ICS CERT обнаружили порядка 20 уязвимостей, и кроме классических уязвимостей – очень странную функциональность, которая позволяла провести эффективную атаку на целевую систему. Подробно можно почитать тут.

А вкратце дело обстоит так: функционал ПО позволял атакующему скрытно получать удаленный доступ, выполнять произвольный код, а также скрывать свое присутствие. Всё, что было нужно для получения доступа к компьютеру, – подключить USB-токен одной из моделей, указанных в таблице выше, подождать пару минут – и отключить токен.
Если на атакованной машине есть доступ в Интернет, происходит автоматическая установка драйвера через Windows Update и службы, автоматически запускается процесс hasplms.exe с правами SYSTEM, открывается порт 1947. Если доступа в Интернет нет, то нужно заставить пользователя установить ПО Gemalto с сайта или в составе ПО третьей стороны. Порт 1947 при этом добавляется в исключения межсетевого экрана Windows. После открытия порта 1947 атакующий по сети мог воспользоваться «плохо документированной API функцией», которая позволяла включать и выключать доступность web интерфейса. Через этот интерфейс можно менять различные настройки программной части решения. В том числе, открывалась возможность менять настройки внутреннего proxy-сервера для обновления языковых пакетов.
Интересный факт: классические защитные механизмы от бинарных уязвимостей (ASLR, Stack Cookie, Stack Canary и т.д.) были отключены разработчиками. И бинарные уязвимости в этих языковых пакетах давали злоумышленникам возможность удаленного выполнения произвольного кода с правами SYSTEM – без особых усилий.
После изменения прокси-сервера, используя внутреннюю логику сервиса, можно получить NTLM-хеш пользователя, из-под которого запущен процесс hasplms.exe (SYSTEM).
Как уже было сказано, компьютер при этом даже может находиться в заблокированном режиме. Перед нами – легитимный функционал, имеющий все признаки бекдора.
Вывод? Доверяй, но проверяй. Желательно, с участием опытных специалистов, понимающих особенности реализации технологий операционных систем и защитного ПО.

История третья, о моделях ИБ. Спасибо, что деньгами

Модели безопасности и, в частности, модели контроля доступа – одна из самых нелюбимых и непонятных тем для студентов. Правила доступа, сформулированные вне привычных концепций файлов и пользователей, кажутся то непонятными, то самоочевидными, а теоремы безопасности забываются после экзамена почти мгновенно.
Однако принципы ограничения потоков данных в соответствии с обязательными правилами нормативного контроля применяются не только для защиты данных, но и для защиты критических инфраструктур, к примеру, вычислительных сетей на объектах атомной промышленности.
Официально цифровизация атомных электростанций началась не слишком давно: в нулевые начиналась в России, а первая полностью цифровая АЭС в США заработала только в 2011 году (источник). Тем не менее, тут и там встречались энтузиасты, дорабатывавшие системы контроля и управления, к примеру, для целей удаленной диагностики. В офисной сети АЭС Хэтч (Hatch) в штате Джорджия, США, использовалось специализированное ПО для наблюдения за химическими и диагностическими данными, получаемыми от основной системы управления. При этом происходила синхронизация хранимых в нем данных с данными в системе управления, расположенной в сегменте сети, изолированном от офисного сегмента.
Оператор знал о важности обновлений безопасности и проводил обновление ПО в офисном сегменте. Однако он не учел, что при перезапуске системы после обновления ПО произойдет удаление всех данных, и синхронизация вызовет удаление данных в связанной системе управления. В свою очередь, система безопасности интерпретировала отсутствие данных в системе управления как потерю охлаждающей воды и в результате инициировала аварийный останов реактора.
Останов реактора в нормальном режиме не был опасен для людей или окружающей среды, однако перезапуск реактора – долгая операция. К тому же, на втором реакторе происходила перегрузка топлива, а значит, АЭС была неспособна поставлять электроэнергию в течение двух суток. По оценкам экспертов, финансовые потери из-за недопоставок составили от 2 до 5 миллионов долларов.
Почему я тут говорю о моделях безопасности? Дело в том, что согласно современным стандартам, на АЭС применяется мандатная модель ограничений доступа. Непредвиденная синхронизация данных в системе управления с офисным компьютером не произошла бы, если бы не прошел сигнал из офисной сети в сеть контроля и управления – а он должен был быть запрещен и отфильтрован на МЭ или при помощи диода данных. Разумеется, ни о каком «собственноручно модифицированном» ПО на АЭС не может быть и речи, однако организационные правила не всегда срабатывают, а хорошо реализованная архитектура безопасности на моделях доступа помогает предотвратить ущерб от ошибок.

Историю четвертую, про 13 портовых друзей Оушена, я просто рекомендую почитать в блоге тут, потому что вряд ли расскажу ее лучше Володи Дащенко
Но позволю себе заметить, что в случае настолько целеустремленных нарушителей нельзя предложить какое-то готовое техническое решение, а работать нужно с фантазией, огоньком и «catch me if you can» в крови. Это плохо стыкуется с той скукотой, которую студенты получают на лекциях по «Организационным и техническим методам защиты информации». И даже с той работой, которую большинство взрослых специалистов делает для организации СУИБ по ISO 27001.
Потому что убрать бумажную безопасность из бумажной безопасности – самое сложное.