Основы междоменных решений (CDS)

[Carder]

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

Управляющее резюме​

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

Об этом руководстве​

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

Резюме​

CDS - это возможность, которую можно использовать для безопасного соединения дискретных систем или сетей. Эти отдельные системы или сети (известные как домены безопасности) могут иметь разные политики безопасности для защиты от подверженности различным типам угроз и уровней риска и, следовательно, иметь разные уровни доверия.
ISM определяет CDS как «систему, способную реализовывать комплексные политики безопасности потока данных с высоким уровнем доверия между двумя или более различными доменами безопасности». Проще говоря, CDS - это гарантированная система, которая выполняет функции безопасности, необходимые для управления потоком информации и данных между доменами безопасности. Таким образом, CDS обеспечивает контролируемое подключение (или укрепляет существующее подключение) к изолированным сетям, например через воздушный зазор. Хотя CDS иногда можно описать как решение X-Domain или XDS, это стилистическое решение, и требования CDS все еще применяются.
Обеспечение безопасного взаимодействия систем поможет организациям:

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

Хотя CDS является ключевым элементом для обеспечения эффективной междоменной безопасности, тщательный подход должен учитывать больше, чем любой отдельный продукт CDS в отдельности. Кроме того, не все проблемы с междоменными доменами можно решить с помощью только технических решений. Человеческий фактор, методы управления информацией и другие бизнес-процессы должны быть всесторонне изучены, чтобы гарантировать внедрение соответствующего решения. Безопасная возможность достижима только в том случае, если эти аспекты учитываются на протяжении всего жизненного цикла возможности.

Почему CDS особенный​

Системы CDS являются примером технологической конвергенции, когда отдельные концепции и технологии безопасности тщательно объединяются в комплексную системную архитектуру для защиты чувствительных, критических и секретных сетей.
В отличие от готового коммерческого сетевого шлюза (COTS), который используется в приложениях с низким уровнем риска, CDS - это усовершенствованная система шлюза, в которой используется широкий спектр перекрывающихся элементов управления безопасностью для обеспечения гарантированных потоков данных и глубокой защиты. . CDS, используемый для защиты секретных систем, специально разработан для решения модели угроз, охватывающей угрозы национальной безопасности, а не только угрозы потребительского типа. Однако одной только реализации мер безопасности будет недостаточно для обеспечения безопасности работы CDS или адекватного выполнения их основных функций.
Центр кибербезопасности (ACSC) рекомендует организациям проводить тщательный анализ рисков безопасности, финансов и устойчивости при рассмотрении бизнес-преимуществ любых предлагаемых CDS в их среде. Чтобы получить уверенность в эффективности функций безопасности, выполняемых CDS, настоятельно рекомендуется систематический анализ рисков и тщательные технические оценки.

Общие варианты использования CDS​

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

Примерные варианты использования CDS включают:

• передача сообщений фиксированного формата между правительственными и военными системами
• передача бизнес-файлов в изолированные системы или из них
• прием массовых операционных данных из конфиденциальной сети в секретную сеть
• агрегирование входных данных из нескольких по-разному классифицированных сред в центральной системе аудита или мониторинга
• доступ к нескольким рабочим областям с разной степенью чувствительности с одного клиентского устройства в наиболее надежной сети.

Общие технологии в CDS​

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

• Устройства CDS или другие междоменные средства защиты
• диоды данных для одностороннего управления потоком данных и завершения сетевого протокола
• ПО и устройства для фильтрации контента
• ПО для оркестрации фильтров и управления рабочими процессами
• антивирусное ПО и детонационные камеры
• ПО для предотвращения потери данных и обнаружения внутренних угроз
• инфраструктура управления идентификацией и доступом
• системы регистрации и аудита
• брандмауэры прикладного уровня.

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

Междоменная безопасность​

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

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

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

Бизнес-цели и угрозы​

Как мы видели, CDS обеспечивает множество преимуществ для организаций и их пользователей, в том числе:

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

Если CDS плохо реализован, угрозы бизнес-целям могут включать:

• потеря эффективности
• непропорционально высокие требования к безопасности (например, увеличение затрат, времени и бизнес-процессов)
• упущенные возможности.

Цели информационной безопасности​

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

• Конфиденциальность: гарантия того, что информация раскрывается только уполномоченным лицам.
• Целостность: гарантия того, что информация и системы не изменяются без разрешения.
• Доступность: гарантия того, что системы доступны и могут использоваться уполномоченными лицами при необходимости.
• Аутентичность: гарантия того, что личность пользователя, процесса или устройства известна и проверена, как предварительное условие для разрешения авторизованного доступа к ресурсам в системе.
• Подотчетность: гарантия того, что происхождение и целостность данных доказаны или что аутентификация может быть подтверждена как подлинная, и любые последующие действия не могут быть отклонены (также известное как неотказуемость).

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

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

Следующая диаграмма иллюстрирует цели информационной безопасности для защиты междоменного соединения.

Распространенные междоменные угрозы​

Агенты угрозы​

Внешние субъекты угроз, обычно пытающиеся скомпрометировать высокий уровень (т.е. более чувствительный или доверенный домен безопасности) через низкую сторону (то есть менее уязвимый или доверенный домен безопасности), могут включать:

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

Внутренние субъекты угроз, обычно активируемые через высокий боковой доступ, могут включать:

• авторизованные пользователи, как непривилегированные, так и привилегированные, что делает возможной утечку данных или компрометацию системы случайно
• уполномоченные администраторы неправильно конфигурируют или не исправляют CDS или другую систему безопасности, что ослабляет безопасность и делает возможным утечку данных или предоставление вредоносного ПО
• злонамеренные или обманутые инсайдеры, осуществляющие шпионаж или вмешательство с участием человека.

Другие субъекты угроз, получаемые через доступ к цепочке поставок в киберпространстве, могут включать:

• разработчики системы принимают неправильное решение по безопасности или делают ошибку во время проектирования, разработки или интеграции системы
• внешние субъекты угроз, пытающиеся вмешаться в критически важные функции безопасности во время проектирования, производства или доставки системы.

В конечном итоге источник угрозы вряд ли имеет значение. Из-за чувствительности и, следовательно, желательности информации, защищенной CDS, они должны быть спроектированы таким образом, чтобы быть устойчивыми ко всем возможным субъектам угроз.

Угрозы​

Угрозы первого порядка для доменов безопасности, нуждающихся в защите с помощью CDS, могут включать:

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

Угрозы второго порядка для CDS и их механизмов обеспечения безопасности могут включать:

• субъекты угроз с низким уровнем доступа, пытающиеся нарушить или ухудшить функциональность безопасности или вызвать небезопасное состояние отказа, а затем активировать любую из угроз первого порядка, тем самым угрожая способности CDS защищать конфиденциальность, целостность и доступность высокой стороны
• злоумышленники, пытающиеся нарушить работу CDS, тем самым угрожая доступности CDS и влияя на междоменные бизнес-операции
• злоумышленники, вмешивающиеся в функции безопасности CDS в цепочке поставок в киберпространстве, тем самым угрожая уверенности CDS в выполнении своих функций и высокой конфиденциальности, целостности и доступности.

Угрозы третьего порядка, влияющие на системы поддержки, используемые CDS, могут включать:

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

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

Сценарии отказа​

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

• Что может выйти из строя?
• Каковы последствия неудачи?
• Где наиболее уязвимые места?
• Каковы резервы или гарантии от сбоев?
• Повлияет ли сбой на репутацию организации или ее способность вести бизнес?
• Привлечет ли сбой внимание органов безопасности?
• Привлечет ли неудача внимание руководства организации?

CDS должна быть спроектирована так, чтобы отказываться безопасно и контролируемым образом. Отключение, компрометация или отказ одного или выбранного количества компонентов не должны приводить к компрометации CDS или домена высокой безопасности.

Общие междоменные риски​

Когда меры безопасности для CDS применяются неадекватно, соединения между разными доменами безопасности могут позволить злоумышленникам:

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

Обратите внимание, что этот список рисков не является полным, и необходимо будет учитывать риски, характерные для каждой CDS. Специализированные мероприятия по оценке угроз и рисков помогут в выявлении таких рисков, наряду с потенциальными стратегиями смягчения и мерами безопасности для их устранения.

Принципы междоменной безопасности​

Принципы междоменной безопасности - это набор идеалов, которые определяют передовой опыт безопасной реализации CDS, который, в свою очередь, помогает определить функциональные возможности безопасности, средства управления безопасностью и другие стратегии смягчения, необходимые для соответствия конкретному варианту использования и среде угроз. Сопоставление принципов междоменной безопасности с функциями и компонентами в проекте системы часто иллюстрируется для целей обсуждения в виде логической декомпозиции, ориентированной на безопасность, или схемы «безопасность с первого взгляда».
Для устранения угроз и рисков, описанных ранее, CDS должен содержать соответствующие контексту функции безопасности, которые применяются в продуманном шаблоне и конфигурации и реализуются с достаточным уровнем гарантии. Эти функции безопасности можно объяснить следующим образом:

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

В контексте управления рисками эти требования могут быть переведены в принципы междоменной безопасности:

• контекстно-зависимые механизмы обеспечения безопасности
• безопасная архитектура и дизайн
• системная гарантия и безопасная работа.

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

Управление рисками CDS​

Ряд факторов усложняют управление рисками CDS. По определению, CDS соединяет отдельные домены безопасности, которые могут работать под разными административными или организационными полномочиями. Кроме того, в любом CDS будут существовать технические риски. Помимо технических стратегий смягчения последствий, вероятно, потребуется значительное количество политик безопасности и процедурных мер для обеспечения надлежащего контроля доступа и использования любых CDS.

Управляемый рисками подход к реализации CDS​

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

Распространенные заблуждения о CDS​

Благодаря активному участию в различных проектах по внедрению CDS, ACSC выявила неправильные представления, связанные с использованием продуктов и систем CDS. Наиболее распространенные из них рассматриваются ниже и должны учитываться при планировании возможностей.

«CDS универсален».​

Хотя компоненты CDS могут быть повторно использованы, действия по оценке рисков и принятию рисков, относящиеся к одной CDS, не могут быть автоматически перенесены на другую. Индивидуальная и продуманная оценка рисков необходима при расширении возможностей CDS за пределы конкретных хорошо изученных сценариев использования и сред угроз, которые легли в основу первоначальных действий по принятию рисков. Кроме того, новые варианты использования могут непреднамеренно снизить безопасность первоначальной реализации. Следовательно, изменения в состоянии безопасности CDS должны быть тщательно оценены на предмет соответствия бизнес-требованиям, чтобы гарантировать полное понимание и приемлемость остаточных рисков.

«CDS - достаточная защита в изоляции».​

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

«CDS безопасен из коробки».​

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

«CDS - это просто и недорого для успешного развертывания».​

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

«CDS - это то же самое, что и оборудование ИКТ с высоким уровнем надежности».​

Чтобы CDS была эффективной, она должна быть построена и протестирована, чтобы продемонстрировать соответствующий уровень уверенности, чтобы поддерживать политики подключенных доменов безопасности. Компоненты CDS имеют высокий уровень доверия, но по мере того, как сложность этих компонентов увеличивается, определение высокого уровня доверия становится все труднее. Несмотря на то, что возможности CDS в целом вряд ли будут оцениваться в рамках программы ACSC High Assurance, использование высоконадежного оборудования ICT в качестве компонентов (например, светодиодов данных) настоятельно рекомендуется там, где это необходимо.
Для сложных систем и платформ, которые реализуют CDS в качестве обеспечивающей или поддерживающей функции, CDS и ее функции безопасности следует рассматривать как критически важные для безопасности всей возможности (и наоборот) во время оценки рисков и действий по принятию рисков.

Отсутствие необходимости в CDS​

Во многих случаях, когда предлагается ввести дополнительные CDS, оптимальным решением для удовлетворения бизнес-требований может быть использование уже существующих CDS или даже отказ от использования CDS в целом. Альтернативные подходы к внедрению дополнительных CDS могут включать:

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

Для сценариев использования, связанных с сетями SECRET или TOP SECRET, подключение этих доменов безопасности без использования гарантированной CDS является нарушением руководства в ISM, и организация будет делать это на свой страх и риск.

Объяснение доменов безопасности​

Следующий контент представляет домены безопасности, основную концепцию, необходимую для контекстуализации CDS. Он также вводит ряд подклассов доменов безопасности и взаимосвязей между ними.

Домены безопасности​

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

• система с единой классификацией безопасности (например, ЗАЩИЩЕНА, СЕКРЕТНО или СОВЕРШЕННО СЕКРЕТНО)
• сообщество интересов с ограничениями возможности выпуска или особыми предостережениями при обращении в рамках единой классификации безопасности (например, только австралийские глаза, только доступ правительства Австралии, возможность передачи, контролируемый отправителем или отсутствие подрядчика)
• сеть для разработки или тестирования с более разрешающей политикой безопасности, но более ограниченной политикой доступа пользователей по сравнению с производственной сетью
• любая внешняя сеть, для которой нет определенной политики безопасности и неограниченного риска (например, Интернет).

Домен безопасности, являющийся типом сети, может быть изображен на сетевой диаграмме как неопределенный набор систем с использованием изображения в форме облака.

Анклав домена безопасности​

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

Высокая сторона и низкая сторона​

Когда два домена безопасности рассматриваются вместе, один домен безопасности будет более надежным, чем другой. Домен безопасности с более высоким уровнем доверия, обычно с более высокой классификацией безопасности или предупреждением, известен как высокая сторона, а иногда и красная сторона или высокий домен. Домен с высоким уровнем безопасности, вероятно, будет иметь более строгие требования к доступу, требованиям обработки и политике безопасности. Он должен поддерживать более высокие уровни целостности и конфиденциальности, а также более высокие уровни доступности, если это не ставит под угрозу другие свойства безопасности.
Менее надежный домен безопасности с более низкой классификацией безопасности, предостережением или политикой безопасности известен как нижняя сторона или иногда нижняя сторона домена. Будет считаться, что он поддерживает более низкие уровни целостности и конфиденциальности, особенно когда этот домен безопасности не имеет определенной политики безопасности (например, Интернет, который является средой, не контролируемой организацией).
Иногда бывает трудно определить различие между доменами безопасности высокой и низкой стороны, поскольку классификация безопасности каждого домена безопасности будет одинаковой. В этом случае владельцы системы CDS берут на себя ответственность за домен высокой безопасности, в то время как все другие подключенные домены безопасности считаются за домен низкого уровня.
Терминология высокой и низкой стороны часто более уместна в сценариях, где конфиденциальность считается наиболее важным свойством безопасности. Взаимосвязь между высоким уровнем доверия и высокой чувствительностью может быть иной для систем, в которых целостность является наиболее важным свойством безопасности, таких как CDS, предназначенная для защиты критически важной инфраструктуры.

Граница домена​

Граница домена - это логическое очертание домена безопасности, где системы, содержащиеся в этом домене безопасности, могут взаимодействовать извне, например, с другими доменами безопасности.
Если нет постоянного интерфейса с какими-либо внешними системами, граница домена будет существовать как воздушный зазор, поскольку необходимое логическое разделение также поддерживается физическим разделением.
В типичной междоменной среде граница домена (также рассматриваемая как граница доверия) будет расположена внутри CDS. Более конкретно, фактическая граница домена в архитектуре CDS, вероятно, будет расположена там, где происходит сетевой мост, нарушение протокола и / или одностороннее управление потоком данных (например, диод данных). Некоторые системные архитектуры могут иначе определять поэтапную границу путем введения промежуточной зоны или домена безопасности, отделенных от других доменов безопасности, между парой диодов данных или аналогичными элементами управления. Это называется схемой диодного сэндвич-дизайна.

Воздушный зазор​

Домен с высоким уровнем безопасности, который отделен или отделен от доменов с меньшей безопасностью посредством физического разделения, считается защищенным воздушным зазором. Примечательно, что автономная сеть или система будет поддерживать высокий уровень безопасности, возможно, за счет коммунальных услуг. Данные могут поступать или покидать воздушные зазоры только через съемные носители или через защищенные CDS.
При регулярном обслуживании системы и установке исправлений существует риск нарушения целостности сети. Пользователи также могут пытаться передавать данные через воздушный зазор неконтролируемым образом. Обратите внимание, что как только вы пропускаете съемный носитель между системами, вы эффективно устраняете или перекрываете воздушный зазор. Существуют публичные примеры того, как злоумышленники и злоумышленники успешно взламывают воздушный зазор с помощью съемных носителей.
Физическая изоляция через воздушный зазор, вероятно, будет поддерживаться или, по крайней мере, очень тщательно контролироваться везде, где важна чрезвычайная безопасность. Примеры включают военные и разведывательные сети, промышленные системы управления, финансовые услуги и жизненно важные системы, такие как медицинское оборудование и авионика.

Зона безопасности, зона доверия и демилитаризованная зона​

В сети зона безопасности - это логическая область в сети с определенным уровнем безопасности. Эта безопасность обычно определяется относительно безопасности другой зоны безопасности, такой как Интернет (где нет доверия). Зоны безопасности, расположенные таким образом, также известны как зоны доверия, которые используются в качестве механизма для создания глубокой защиты в структуре сети.
В отличие от надлежащего домена безопасности, зона безопасности или зона доверия может не иметь собственной определенной или принудительной политики безопасности. Скорее, обеспечение безопасности обычно ограничивается логическим разделением сети и правилами управления доступом.
Демилитаризованная зона (DMZ) - это специализированная форма зоны безопасности с одним или несколькими серверами, которые хранятся отдельно от базовой сети, либо за пределами брандмауэра базовой сети, либо как отдельная сеть, защищенная брандмауэром.
DMZ используются для предотвращения прямого доступа к информации и услугам во внутренних сетях. DMZ обычно предоставляют выборку информации и услуг менее надежным сетям, таким как Интернет. DMZ не обязательно обеспечивает дополнительные функции безопасности, она просто обеспечивает уровень разделения сети для серверов, которые должны быть доступны извне. Следовательно, DMZ может рассматриваться как тип домена безопасности и тип зоны доверия.
Если DMZ и внутренняя сеть защищены одним брандмауэром, также известным как трехсторонний брандмауэр, это, вероятно, представляет собой единую точку отказа между общедоступной и внутренней зонами. Например, общедоступный веб-сервер, расположенный в демилитаризованной зоне, разрешит доступ к этому серверу как из Интернета (нижняя сторона), так и из внутренней сети (верхняя сторона), при этом запрещая ненадежным пользователям доступ к внутренней сети.

Соединения между доменами безопасности​

Временные соединения между доменами безопасности​

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

Постоянные соединения между доменами безопасности​

Диод данных, сетевой шлюз и CDS являются примерами постоянных соединений между доменами безопасности. Без всестороннего применения политики безопасности и других мер безопасности, таких как гарантированная и приемлемая система CDS, постоянное соединение с доменом безопасности, в противном случае закрытым, вероятно, подорвет преимущества безопасности, обеспечиваемые воздушным зазором.

Модели безопасности домена​

Несколько независимых уровней безопасности​

Стандартная модель безопасности домена известна как несколько независимых уровней безопасности (MILS). Согласно модели MILS, обычно существует один домен безопасности для каждой классификации безопасности или уровня чувствительности для каждой организации. Например, государственное учреждение может иметь ОФИЦИАЛЬНУЮ или ЗАЩИЩЕННУЮ сеть, подключенную к Интернету, и СЕКРЕТНУЮ сеть. Концепция высокой и низкой стороны является артефактом раздельного характера модели MILS. Благодаря своей простоте и легкости достижения сегрегации эта модель широко используется в правительстве.
На следующей диаграмме показано, как пользователь, получивший уровень «A», может получить доступ к системам и объектам в «Домене A», а пользователь, получивший разрешение «B», может получить доступ к системам и объектам в «Домене B», включая любые объекты, переданные из «Домена». A 'через CDS или другой утвержденный процесс передачи данных.

Многоуровневая безопасность​

Альтернативная модель безопасности домена известна как многоуровневая безопасность (MLS). Вместо того, чтобы сосредоточиться на подключении независимых сред, реализации MLS состоят из единой системы, которая хранит информацию, помеченную на всех уровнях безопасности, и соответственно обеспечивает соблюдение правил доступа.
Согласно модели MLS, все информационные атрибуты должны быть помечены, включая атрибуты уровня безопасности и списка управления доступом. Хотя возможности MLS могут принести много преимуществ для бизнеса, сложность управления этими системами означает, что достижение истинной безопасности может быть трудным и дорогостоящим, особенно потому, что целостность и происхождение маркировки информации должны поддерживаться на протяжении всего срока службы информации.
Практический пример модели MLS находится в операционной системе SELinux. Когда оно работает в режиме MLS, безопасное ядро может осуществлять посредничество между различными частями операционной системы, которые имеют разные уровни безопасности. Системы, построенные с использованием SELinux, который внутренне следует модели MLS, по-прежнему могут быть включены в среду MILS.
На следующей диаграмме показано, как пользователь, получивший разрешение на уровень «A», может получить доступ к информации, помеченной как «A», а пользователь, получивший разрешение на оба уровня «A» и «B», может получить доступ к информации, помеченной как «A» или «B».

CDS объяснил​

Этот контент представляет CDS более подробно, объясняя основные функции CDS и классифицируя ряд подклассов CDS и связанных систем. Он основан на знаниях, содержащихся в более раннем содержании.

Обзор CDS​

CDS - это решение безопасности, которое обеспечивает возможность доступа и / или передачи информации между двумя или более разными доменами безопасности и способное реализовывать комплексные политики безопасности потока данных с высоким уровнем доверия. Гарантированную CDS можно описать как «надежную среду шлюза, которая спроектирована, построена и протестирована для конкретного варианта использования и высокого уровня доверия к тому, что она будет работать, как ожидалось».
CDS обеспечивает механизмы управления информационным потоком на каждом уровне модели OSI с более высоким уровнем гарантии, чем сетевые шлюзы. В отличие от сетевого шлюза, CDS использует широкий спектр средств управления безопасностью для обеспечения комплексной фильтрации содержимого и глубокой защиты.
По мере увеличения сложности данных, проходящих через CDS, становится все труднее получить высокую степень уверенности в процессе проверки, обрабатывающем эти данные. Впоследствии с этой сложностью увеличивается риск утечки данных или импорта вредоносных программ. Ограничение количества допустимых типов данных составляет важную часть спецификации возможностей CDS.
В зависимости от развертывания использование брандмауэров, контролирующих доступ к CDS (как из доменов с низкой, так и с высокой стороны), может быть необязательным, но рекомендуется. Иногда будет целесообразно включить брандмауэры в область действия или границы CDS, а иногда они будут включены в область или границу подключенных доменов безопасности.
CDS предназначен для безопасного решения двух общих бизнес-требований: разрешение передачи данных в и / или из секретного или секретного домена безопасности; или обеспечение одновременного доступа к информации из нескольких источников по нескольким классам защиты.

CDS функции​

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

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

Сравнение с сетевыми шлюзами​

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

Междоменное решение	Сетевой шлюз
Подключает домены безопасности на нескольких уровнях доверия	Обычно подключает домены безопасности на одном уровне доверия (хотя сетевые шлюзы также используются между ОФИЦИАЛЬНЫМИ или ЗАЩИЩЕННЫМИ сетями и Интернетом)
Надежная фильтрация контента на уровне приложения	Фильтрация протоколов на сетевом и, возможно, прикладном уровне
Контролирует транзакции приложений	Управляет сетевыми подключениями
Разрешено несколько сетевых сервисов	Разрешены многие сетевые сервисы
Нарушает протоколы передачи данных	Обычно без нарушения протокола
Использует проверенные платформы	Обычно нет поддержки доверенных платформ
Использует несколько доверенных подсистем	Как правило, одно устройство или прибор
Как правило, в дополнение к продуктам COTS используются индивидуальные решения или готовые продукты для государственных нужд (GOTS) или военные (MOTS).	COTS продукт
Более высокий уровень гарантии безопасности	Обычно более низкие уровни гарантии безопасности

Типы CDS​

Функционально CDS необходимо явно контролировать поток данных между доменами безопасности, обеспечивая соблюдение определенной политики безопасности с помощью технических средств. Однако, в зависимости от варианта использования, CDS можно разделить на один из следующих типов:

• Передача: для облегчения перемещения информации и / или файлов между доменами безопасности.
• Доступ: для обслуживания нескольких рабочих столов пользователей или приложений, которые могут размещаться в разных доменах безопасности.
• Многоуровневая безопасность: введение отдельного домена безопасности, обеспечивающего детальный контроль доступа для каждого объекта данных.

Передача CDS (однонаправленная)​

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

Передача CDS (двунаправленная)​

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

Передача CDS (предприятие)​

ECDS - это крупномасштабные системы передачи или массив систем, разработанные и развернутые для обслуживания общих потребностей в передаче данных между доменами всей организации. Обычно они соединяют несколько доменов безопасности с общей структурой для работы, управления, политики безопасности, аудита и мониторинга.
Бизнес-требования, стимулирующие внедрение eCDS, могут создать серьезные проблемы для достижения междоменной безопасности. Электронная CDS должна быть разработана с особой тщательностью, чтобы обеспечить надлежащее управление рисками. Риски, характерные для eCDS, включают:

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

Обратите внимание, что некоторые бизнес-требования могут быть лучше выполнены с помощью CDS с двухточечной передачей, развернутой вместе с eCDS. Кроме того, учитывая риски, связанные с реализацией новых возможностей eCDS, альтернативный подход может заключаться в использовании общей архитектуры или шаблона проектирования для предоставления нескольких дискретных решений для различных вариантов использования или требований к подключению.

Передача CDS (специализированные реализации)​

Другие реализации CDS существуют как COTS, GOTS, MOTS или специальные возможности для удовлетворения конкретных бизнес-требований. К ним относятся CDS для шлюзов голосовых и видеоконференций, почтовых шлюзов, репликации базы данных, сбора аудита и потокового видео.
Независимо от бизнес-требований, специализированная CDS в конечном итоге будет реализацией одного из уже описанных базовых типов CDS. Специализация проистекает из оптимизации производительности и добавления жестко ограниченной политики безопасности, адаптированной для устранения угроз и рисков, применимых к требованиям нишевых данных.

Междоменные охранники​

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

Доступ к CDS​

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

Доступ к CDS (пролистайте вниз)​

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

Доступ к CDS (поиск)​

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

Системы MLS​

Модель MLS позволяет системе MLS обрабатывать информацию с различными классификациями безопасности путем пометки информации маркерами классификации безопасности. Это, в свою очередь, разрешает одновременный доступ пользователям с разными уровнями доступа или разрешениями. Цель этого подхода - способствовать сотрудничеству, не позволяя пользователям получать доступ к информации, для которой у них нет авторизации.
Системы MLS разрешают доступ к менее секретной информации персоналу с более высоким уровнем допуска, а также позволяют им обмениваться дезинфицированной информацией с персоналом, имеющим более низкий уровень допуска в рамках той же системы. В этой ситуации дезинфекция информации относится к удалению или изменению контента, чтобы информация больше не требовала более высокого уровня допуска для доступа. В результате системы MLS устраняют необходимость дублировать информацию в разных доменах безопасности.
Одной из ключевых функций безопасности систем MLS является то, что пользователи не могут напрямую получить доступ к подключенным доменам безопасности. Следовательно, система MLS может быть желательной, когда пользователи не имеют доступа к одному и тому же уровню, но должны работать вместе с различной информацией в одной и той же среде.
Системы, использующие MLS, обязательно сложны с многочисленными неограниченными рисками. Таким образом, очень сложно обеспечить гарантии. Для получения дополнительных рекомендаций по использованию систем MLS необходимо связаться с ACSC, поскольку в настоящее время в Австралии не существует таких разрешенных внедрений.

Комбинированный доступ и передача CDS​

В некоторых случаях вышеупомянутые типы CDS могут быть объединены, чтобы позволить пользователям получать доступ и передавать информацию в одном или нескольких направлениях между доменами безопасности с одного клиентского устройства. Эта архитектура фактически представляет собой комбинацию одной или нескольких CDS доступа и CDS передачи между двумя или более доменами безопасности. В таких случаях информация не будет передаваться между соответствующими доменами безопасности, за исключением случаев, когда это явно указано и разрешено для передачи. Как и в случае с CDS доступа, пользователи будут допущены как минимум до уровня наивысшего уровня безопасности. Комбинированное решение для доступа и передачи, вероятно, потребует интеграции между функциями, чтобы обеспечить пользователям удобство работы.
Эти типы CDS ранее были описаны как многоуровневые CDS из-за использования в них комбинации технологии CDS для обеспечения некоторых внешних функций систем MLS. На следующей диаграмме показана возможная реализация, сочетающая функции CDS доступа и передачи.

Принципы междоменной безопасности​

Как отмечалось ранее, CDS должен учитывать следующие принципы междоменной безопасности:

• контекстно-зависимые механизмы обеспечения безопасности
• безопасная архитектура и дизайн
• системная гарантия и безопасная работа.

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

Соответствующие контексту механизмы обеспечения безопасности​

Применение политики безопасности​

CDS будет обеспечивать соблюдение политики безопасности, разработанной для удовлетворения требований организации по обмену информацией, при одновременном соблюдении предположений о безопасности и принятии рисков, присущих домену высокой безопасности.
Политика безопасности должна учитывать совместно используемую информацию (то есть семантическое содержание) и формат данных, используемый для передачи этой информации (то есть синтаксис или синтаксическую структуру). CDS должен проверять все содержимое файлов и любые другие данные по схеме известного и ожидаемого трафика. Кроме того, CDS гарантирует, что вся информация, включая тип данных, контент, источник и отправителя, одобрена для выпуска в соответствии с политикой безопасности или надежно реализованным процессом ручного вмешательства, который выявляет любой скрытый контент для знающего рецензента.
Дополнительную информацию о применении политики безопасности можно найти в Руководстве ISM по передаче данных и фильтрации содержимого .

Блокируйте сначала, задавайте вопросы позже​

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

Предотвращение вредоносного ПО​

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

Защита от потери данных​

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

Авторизация доступа​

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

Источник данных​

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

Преобразование и нормализация​

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

Обрыв протокола​

CDS будет действовать как сетевой прокси и завершать транспортные протоколы на нескольких уровнях модели OSI для всего сетевого трафика.
Этот разрыв протокола помогает CDS защитить верхнюю сторону от вредоносного сетевого трафика и протоколов прикладного уровня. Например, на транспортном уровне (уровень 4 модели OSI) соединения протокола управления передачей могут быть разорваны и повторно переданы с использованием протокола дейтаграмм пользователя.

Односторонний поток​

CDS будет обеспечивать однонаправленные потоки данных с использованием односторонних компонентов управления и односторонних каналов связи между процессами.
Направление потоков данных не будет изменено в течение срока эксплуатации CDS без утверждения. Для передачи данных через одностороннее управление, такое как диод данных, обычно используется протокол без сохранения состояния, которому способствует разрыв протокола.

Управление потоком​

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

Безопасная архитектура и дизайн​

Изоляция домена​

Организации будут иметь архитектуру, которая разделяет информацию и системы на отдельные домены безопасности с общей политикой безопасности.
Скорее всего, это будет сделано в соответствии с классификацией чувствительности или безопасности и является предварительным условием для наиболее эффективного использования CDS. Эти изолированные домены безопасности с физическим, логическим и / или криптографическим разделением считаются защищенными воздушным зазором, отражающим преднамеренное отсутствие возможности подключения к внешней среде.
Домен безопасности придерживается этого принципа междоменной безопасности, если единственный способ передать или получить доступ к информации из изолированного домена безопасности - через гарантированный CDS или другой утвержденный процесс, который поддерживает логическую сегментацию и сегрегацию сети.
Дополнительную информацию можно найти в публикации ACSC по реализации сегментации и сегрегации сети .

Предварительно утвержденные шаблоны​

CDS будет следовать шаблонам архитектуры и / или шаблонам проектирования, если они одобрены и доступны разработчикам системы, чтобы гарантировать последовательное и безопасное устранение рисков, связанных с общими проблемами безопасности.
Шаблоны архитектуры разрабатываются для ряда общих бизнес-требований и могут быть запрошены в ACSC.

Индивидуальные решения​

CDS будет адаптирован к конкретным деловым, эксплуатационным требованиям и требованиям безопасности владельцев систем CDS.
Хотя компоненты CDS могут быть повторно использованы, особенно в случае использования предварительно утвержденной архитектуры или шаблонов проектирования, действия по оценке рисков и принятию рисков, относящиеся к одной CDS, не могут быть автоматически перенесены на другую.
Индивидуальная и продуманная оценка рисков необходима при расширении возможностей CDS за пределы конкретных хорошо понятных сценариев использования и сред угроз, которые легли в основу первоначальных действий по принятию рисков. Кроме того, новые варианты использования могут непреднамеренно снизить безопасность первоначальной реализации. Следовательно, изменения в состоянии безопасности CDS должны быть тщательно оценены на предмет соответствия бизнес-требованиям, чтобы гарантировать полное понимание и приемлемость остаточных рисков.

Глубокая защита​

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

Безопасный дизайн​

CDS будет разработан для решения проблем безопасности, прежде всего, с добавлением функциональных возможностей по мере необходимости для удовлетворения бизнес-требований.
Проекты системы CDS должны решать проблемы безопасности, а не слепо применять меры безопасности к существующей системе. Крайне важно, чтобы безопасность обеспечивалась на протяжении всего процесса разработки и внедрения, а не закреплялась в конце.

Простота​

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

Без обхода​

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

Разделение​

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

Уменьшение поверхности атаки​

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

Снижение риска каскадных соединений​

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

Надежность системы и безопасная работа​

Формальное системное обеспечение​

Владельцы системы CDS должны гарантировать, что возможности CDS пройдут формальный процесс оценки системы и будут приняты все рекомендации.
Чтобы гарантировать, что проекты, включающие CDS, не застопорились из-за формальной деятельности по обеспечению гарантий системы, владельцы системы CDS будут учитывать эти действия в графиках проекта и планировать любые потенциальные сбои или обнаружение неприемлемого риска. Чтобы снизить этот риск, владельцы системы CDS должны заранее связаться с соответствующими органами безопасности и следовать любым полученным советам.

Надежные платформы и компоненты​

CDS будет использовать платформы и компоненты, разработанные и гарантированные для обеспечения безопасности, особенно для критических механизмов обеспечения безопасности.
CDS должен использовать компоненты, которые были оценены в рамках программы оценки высокой надежности ACSC или взаимно признаны ACSC, если они доступны и подходят. Это гарантирует, что техническая, физическая и процедурная защита компонентов достаточна для устранения угроз национальной безопасности. Разработчики систем и интеграторы также должны внедрить безопасную цепочку киберпоставок для компонентов программного и аппаратного обеспечения, чтобы гарантировать, что они не будут скомпрометированы во время разработки и производства.
Платформы и компоненты также должны быть усилены, следуя Стратегиям ACSC по смягчению инцидентов кибербезопасности и другим руководствам по усилению защиты системы, таким как Техническое руководство по внедрению безопасности, разработанное Агентством оборонных информационных систем США. Такие действия по усилению защиты должны включать удаление или стерилизацию ненужных пользователей (например, пользователей системы, в частности, «root») и функциональных возможностей (например, модулей ядра, инструментов разработчика и любого неиспользуемого стороннего программного обеспечения).

Безопасное администрирование​

CDS будет использовать безопасные методы администрирования.
Методы безопасного администрирования включают, но не ограничиваются:

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

Подотчетность и обнаружение​

CDS будет использовать рекомендации ACSC по передовому аудиту для создания и хранения значимых сообщений аудита и регистрации.
CDS должна использовать значимый системный мониторинг и оповещения, чтобы способствовать целостности и доступности системы, и не полагаться на наблюдение человека. Эта функция должна включать инструменты мониторинга, которые настроены для автоматического профилирования нормального делового поведения и предупреждения о значительных изменениях и аномальном поведении.
Дополнительную информацию можно найти в Руководстве ISM по мониторингу системы и в публикации ACSC по регистрации и пересылке событий Windows.

Самозащита​

CDS будет использовать пассивные и активные меры самозащиты.
Реализации безопасных CDS должны защищать себя от прямых атак, а также атак через каналы данных, направленных на воздействие на подключенные домены безопасности. CDS должен также включать меры по предотвращению любого компромисса, который может закрепиться при достижении устойчивости в системе. Кроме того, компоненты CDS должны использовать надежный процесс загрузки и работать только в четко определенных состояниях. Например, настройка и работа системы никогда не должны происходить одновременно. Наконец, механизмы обеспечения безопасности, которые предназначены для обработки сложных типов данных, должны быть сброшены между каждым сеансом, чтобы обеспечить чистую среду выполнения для программного обеспечения фильтрации.
CDS также должна реализовывать функции для выявления возникающих уязвимостей безопасности в своем стеке приложений автоматизированным и чувствительным ко времени способом, особенно для любых общедоступных или подключенных к Интернету компонентов. Базовое оборудование механизмов обеспечения безопасности также должно использовать меры физического обнаружения и предотвращения несанкционированного доступа. Более сложные системы могут также включать дополнительные функции обнаружения и предотвращения вторжений в зонах CDS.
Наконец, любые процессы утверждения выпуска должны проверять внутреннее происхождение данных и проверять целостность механизмов обеспечения безопасности, через которые прошли данные (например, подписание оркестратором фильтра содержимого или аналогичным процессом). В дополнение к пассивной защите метаданные управления и контроля CDS должны быть проверены и коррелированы с другими журналами CDS (например, разрешениями на выпуск).

Безопасный отказ​

CDS выйдет из строя безопасно, так что отключение, компрометация или отказ отдельного компонента или выбранного количества компонентов не должны привести к компрометации безопасности CDS или домена высокой безопасности.
Определение безопасного отказа зависит от целей информационной безопасности, которые CDS намеревается достичь. Обычно цель состоит в том, чтобы гарантировать целостность и / или конфиденциальность информации, и в этом случае сбой защиты приведет к блокировке всей информации CDS до тех пор, пока безопасные операции не будут возобновлены. Однако это может быть нежелательно, если доступность информации определяется как наиболее важное требование бизнеса. В этом случае необходимо сгенерировать критическое предупреждение, чтобы можно было использовать альтернативную систему или метод, пока неисправность расследуется в срочном порядке.
Владельцы систем CDS должны иметь план управления любыми отказами компонентов или систем. Точно так же CDS не должно быть разрешено работать в ухудшенном состоянии, когда безопасная работа механизмов обеспечения безопасности и функций аудита не может быть гарантирована.

Непрозрачная операция​

CDS будет работать непрозрачно и не передавать информацию о высокой стороне или о себе системам или пользователям с низкой стороны.
Неудачные операции не должны обеспечивать обратную связь, связанную с безопасностью, или иным образом предоставлять пользователям новую информацию.

Обеспечение безопасности и оперативная поддержка​

Владельцы систем CDS будут поддерживать уровень безопасности своих систем CDS и связанных с безопасностью систем.
Администраторы как можно скорее будут применять исправления и системные обновления к операционным системам, программным библиотекам, спискам сигнатур защиты от вредоносных программ и другим компонентам. При этом любые обновления или модификации должны соответствовать утвержденным процедурам контроля изменений и отражаться в официальной документации системы. Кроме того, исправления и обновления системы должны иметь гарантированное происхождение и, по возможности, поступать из домена с самым высоким и, следовательно, наиболее надежным доменом безопасности.

Обзор безопасности​

Владельцы системы CDS будут регулярно контролировать и пересматривать свое состояние безопасности, как это согласовано с соответствующим уполномоченным должностным лицом.
Владельцы систем CDS должны осознавать, что опасные среды и технологии не статичны. Технологии CDS значительно выросли и продолжают развиваться с тех пор, как были впервые разработаны многие унаследованные продукты и возможности.
Обратите внимание, что процесс управления рисками, определенный в ISM, включает этап непрерывного мониторинга, который гарантирует, что влияние изменений на среду угроз и любые компоненты, относящиеся к безопасности, учитываются, а риски управляются своевременно.

Обучение пользователей​

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

Гарантия безопасности​

CDS снижает риски передачи данных в сети и из них с высоким уровнем гарантии. То есть с высокой степенью уверенности в том, что функции безопасности работают так, как предназначены для защиты подключенных доменов безопасности. Чтобы облегчить это, важно понимать риски, характерные для каждого варианта междоменного использования, поскольку CDS разработан для удовлетворения конкретных бизнес-требований организации и среды рисков. Кроме того, планирование, проектирование, установка и обслуживание любых CDS должны основываться на тщательном управлении рисками.
По сравнению с обычной практикой кибербезопасности, применение междоменных мер безопасности предназначено для защиты наиболее конфиденциальных или секретных систем и информации организации, поэтому необходимы более высокие уровни уверенности. Общие передовые методы кибербезопасности по-прежнему применимы к CDS, однако хорошо спроектированная CDS обеспечит применение и многоуровневость принципов междоменной безопасности таким образом, чтобы отказ или компрометация одного компонента или даже нескольких компонентов не могли привести к компромиссу. любых подключенных доменов безопасности.
В некоторых организациях есть специальные консультативные органы, которые являются экспертами по предметным областям CDS и действуют от имени ACSC, чтобы предоставлять индивидуальные консультации и помощь. ACSC рекомендует, чтобы проекты, включающие CDS, взаимодействовали с командой безопасности своей организации и любыми консультативными органами CDS на ранней стадии и часто для обеспечения всестороннего понимания рисков и управления ими. Аналогичным образом, если это руководство не отвечает на какие-либо вопросы, обратитесь в службу безопасности вашей организации, консультативный орган CDS или ACSC.

Меры безопасности и стратегии смягчения​

Средства управления безопасностью расширяют принципы междоменной безопасности, чтобы обеспечить практические стратегии смягчения последствий, которые могут быть реализованы с использованием подхода управления рисками для обеспечения безопасной конфигурации для CDS. ACSC может предоставить ряд таких средств управления безопасностью для реализаций CDS по запросу, чтобы дополнять контент в ISM.
Обратите внимание, что не все меры безопасности будут актуальны для всех систем CDS. Точно так же не предполагается, что дополнительные меры безопасности должны рассматриваться как список соответствия. Требуется тщательный анализ, чтобы гарантировать, что технические, физические, кадровые, политические и процедурные меры безопасности применяются для достаточного соблюдения принципов междоменной безопасности, описанных в этом руководстве.
Как и в случае с любой другой системой, стратегии ACSC по смягчению инцидентов кибербезопасности , включая Essential Eight, также применимы к реализациям CDS.

Шаблоны архитектуры​

Шаблоны архитектуры системы, шаблоны проектирования и другие эталонные архитектуры для CDS предназначены для помощи разработчикам систем и интеграторам, выполняющим работу над CDS, посредством:

• повышение осведомленности об эффективных и безопасных решениях для общих бизнес-требований
• понимание возможностей и ограничений шаблона системной архитектуры в контексте более широкой системы
• определение роли и требований, предъявляемых к каждому компоненту шаблона архитектуры системы.

Шаблоны архитектуры разрабатываются для ряда общих бизнес-требований и могут быть запрошены в ACSC.

Принятие риска​

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

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

Обратите внимание, что уровень участия группы ACSC по консультированию и оценке CDS во время этих мероприятий будет регулироваться в индивидуальном порядке.

Следующий шаг​

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