Многоуровневая безопасность компьютерных систем.

Введение

Применение компьютерной системы

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

Доверенные операционные системы

Операционная среда MLS часто требует высоконадежной системы обработки информации, часто построенной на операционной системе MLS (OS), но не обязательно. Большинство функций MLS может поддерживаться системой, полностью состоящей из ненадежных компьютеров, хотя это требует нескольких независимых компьютеров, соединенных каналами, соответствующими требованиям безопасности оборудования (см. раздел B.6.2 Интерпретации надежной сети, NCSC TG 005). Примером аппаратно-принудительного MLS является асимметричная изоляция. Если компьютер используется в режиме MLS, то он должен использовать надежную операционную систему (OS). Поскольку вся информация в среде MLS физически доступна для операционной системы, должны существовать строгие логические средства контроля для обеспечения строгого контроля доступа к информации. Обычно это включает в себя обязательный контроль доступа, использующий метки безопасности, такие как модель Bell–LaPadula. Клиенты, развертывающие надежные операционные системы, обычно требуют, чтобы продукт прошел формальную оценку компьютерной безопасности. Оценка становится строже для более широкого диапазона безопасности, определяемого минимальным и максимальным уровнями классификации, которые система может обрабатывать. Критерии оценки надежных компьютерных систем (TCSEC) были первыми критериями оценки, разработанными для оценки MLS в компьютерных системах. В рамках этих критериев существовало четкое и единообразное соответствие между требованиями безопасности и шириной диапазона безопасности MLS. Исторически, лишь немногие реализации были сертифицированы как способные к обработке MLS в диапазоне безопасности от неклассифицированной до совершенно секретной. Среди них – SCOMP от Honeywell, USAF SACDIN, Blacker от NSA и MLS LAN от Boeing, все сертифицированы по TCSEC, выпущены в 1980-х годах и основаны на Intel 80386. В настоящее время продукты MLS оцениваются в соответствии с Общими критериями. В конце 2008 года первая операционная система (подробнее ниже) была сертифицирована на высокий уровень заверения: Уровень заверения (EAL) EAL 6+ / Высокая надежность, в рамках правительственной программы США, требующей многоуровневой безопасности в условиях высокой угрозы. Хотя этот уровень заверения имеет много общего со старым «Оранжевым книгой» A1 (например, формальные методы), функциональные требования сосредоточены на фундаментальной изоляции и политиках потока информации, а не на политиках более высокого уровня, таких как Bell–LaPadula. Поскольку Общие критерии отделили соответствие TCSEC между уровнем заверения (EAL) и функциональностью (Профиль защиты), четкое и единообразное соответствие между требованиями безопасности и возможностями диапазона безопасности MLS, задокументированное в CSC STD 004 85, в значительной степени было утрачено, когда Общие критерии заменили серию Rainbow. Бесплатно доступные операционные системы с некоторыми функциями, поддерживающими MLS, включают Linux с включенной функцией Security Enhanced Linux и FreeBSD. Оценка безопасности когда-то считалась проблемой для этих бесплатных реализаций MLS по трем причинам: всегда очень сложно реализовать стратегию самозащиты ядра с точностью, необходимой для доверия MLS, и эти примеры не были разработаны или сертифицированы для профиля защиты MLS, поэтому они могут не обеспечивать самозащиту, необходимую для поддержки MLS. Помимо уровней EAL, в Общих критериях отсутствует перечень соответствующих профилей защиты с высокой степенью уверенности, определяющих надежность, необходимую для работы в режиме MLS. Даже если бы (1) и (2) были выполнены, процесс оценки очень дорог и налагает особые ограничения на контроль конфигурации оцениваемого программного обеспечения. Несмотря на такие предположения, Red Hat Enterprise Linux 5 была сертифицирована по LSPP, RBACPP и CAPP на уровне EAL4+ в июне 2007 года. Она использует Security Enhanced Linux для реализации MLS и стала первой сертификацией Common Criteria, обеспечивающей соблюдение свойств безопасности TOE с использованием Security Enhanced Linux. Стратегии сертификации поставщиков могут вводить в заблуждение неспециалистов. Распространенная стратегия использует чрезмерное внимание неспециалистов к уровню EAL с чрезмерной сертификацией, например, сертификация профиля защиты EAL 3 (например, CAPP) на более высоких уровнях, таких как EAL 4 или EAL 5. Другая – добавление и сертификация функций поддержки MLS (таких как профиль защиты контроля доступа на основе ролей (RBACPP) и профиль защиты безопасности с метками (LSPP)) в ядро, которое не оценивалось по профилю защиты, способному к MLS. Эти функции являются службами, работающими на ядре, и зависят от ядра для защиты от повреждений и подрыва. Если ядро не оценивалось по профилю защиты, способному к MLS, функции MLS не могут быть надежными, независимо от того, насколько впечатляющей выглядит демонстрация. Особенно важно отметить, что CAPP специально не является профилем, способным к MLS, поскольку он специально исключает возможности самозащиты, критически важные для MLS. General Dynamics предлагает PitBull, надежную операционную систему MLS. В настоящее время PitBull предлагается только как улучшенная версия Red Hat Enterprise Linux, но более ранние версии существовали для Sun Microsystems Solaris, IBM AIX и SVR4 Unix. PitBull предоставляет механизм безопасности Bell–LaPadula, механизм целостности Biba, замену суперпользователя привилегиями и многие другие функции. PitBull является базой безопасности для продукта General Dynamics Trusted Network Environment (TNE) с 2009 года. TNE обеспечивает многоуровневый обмен информацией и доступ для пользователей в Министерстве обороны и разведывательном сообществе, работающих с различными уровнями классификации. Он также является основой для среды многоуровневого обмена информацией между союзниками, Battlefield Information Collection and Exploitation Systems Extended (BICES X). Sun Microsystems, ныне Oracle Corporation, предлагает Solaris Trusted Extensions как интегрированную функцию коммерческих ОС Solaris и OpenSolaris. В дополнение к профилю защиты контролируемого доступа (CAPP) и профилям защиты контроля доступа на основе ролей (RBAC), Trusted Extensions также были сертифицированы на уровне EAL4 по профилю защиты безопасности с метками (LSPP). Цель оценки включает в себя функциональность как для настольных компьютеров, так и для сети. LSPP требует, чтобы пользователи не имели права отменять политики маркировки, применяемые ядром и X Window System (X11 server). Оценка не включает анализ скрытых каналов. Поскольку эти сертификации зависят от CAPP, ни одна сертификация Common Criteria не указывает на то, что этот продукт надежен для MLS. BAE Systems предлагает XTS 400, коммерческую систему, поддерживающую MLS с тем уровнем гарантии, на который претендует поставщик. Предыдущие продукты (включая XTS 300) были оценены на уровне TCSEC B3, который способен к MLS. XTS 400 был оценен в соответствии с Общими критериями на уровне EAL5+ по профилям защиты CAPP и LSPP. CAPP и LSPP – это профили защиты EAL3, которые не являются по своей сути способными к MLS, но цель оценки для оценки Common Criteria этого продукта содержит расширенный набор функций безопасности, обеспечивающих возможности MLS.

An MLS operating environment often requires a highly trustworthy information processing system often built on an MLS operating system (OS), but not necessarily. Most MLS functionality can be supported by a system composed entirely from untrusted computers, although it requires multiple independent computers linked by hardware security compliant channels (see section B.6.2 of the Trusted Network Interpretation, NCSC TG 005). An example of hardware enforced MLS is asymmetric isolation. If one computer is being used in MLS mode, then that computer must use a trusted operating system (OS). Because all information in an MLS environment is physically accessible by the OS, strong logical controls must exist to ensure that access to information is strictly controlled. Typically this involves mandatory access control that uses security labels, like the Bell–LaPadula model. Customers that deploy trusted operating systems typically require that the product complete a formal computer security evaluation. The evaluation is stricter for a broader security range, which are the lowest and highest classification levels the system can process. The Trusted Computer System Evaluation Criteria (TCSEC) was the first evaluation criteria developed to assess MLS in computer systems. Under that criteria there was a clear uniform mapping between the security requirements and the breadth of the MLS security range. Historically few implementations have been certified capable of MLS processing with a security range of Unclassified through Top Secret. Among them were Honeywell's SCOMP, USAF SACDIN, NSA's Blacker, and Boeing's MLS LAN, all under TCSEC, 1980s vintage and Intel 80386 based. Currently, MLS products are evaluated under the Common Criteria. In late 2008, the first operating system (more below) was certified to a high evaluated assurance level: Evaluation Assurance Level (EAL) EAL 6+ / High Robustness, under the auspices of a U. S. government program requiring multilevel security in a high threat environment. While this assurance level has many similarities to that of the old Orange Book A1 (such as formal methods), the functional requirements focus on fundamental isolation and information flow policies rather than higher level policies such as Bell La Padula. Because the Common Criteria decoupled TCSEC's pairing of assurance (EAL) and functionality (Protection Profile), the clear uniform mapping between security requirements and MLS security range capability documented in CSC STD 004 85 has largely been lost when the Common Criteria superseded the Rainbow Series. Freely available operating systems with some features that support MLS include Linux with the Security Enhanced Linux feature enabled and FreeBSD. Security evaluation was once thought to be a problem for these free MLS implementations for three reasons:

It is always very difficult to implement kernel self protection strategy with the precision needed for MLS trust, and these examples were not designed to or certified to an MLS protection profile so they may not offer the self protection needed to support MLS. Aside from EAL levels, the Common Criteria lacks an inventory of appropriate high assurance protection profiles that specify the robustness needed to operate in MLS mode. Even if (1) and (2) were met, the evaluation process is very costly and imposes special restrictions on configuration control of the evaluated software. Notwithstanding such suppositions, Red Hat Enterprise Linux 5 was certified against LSPP, RBACPP, and CAPP at EAL4+ in June 2007. It uses Security Enhanced Linux to implement MLS and was the first Common Criteria certification to enforce TOE security properties with Security Enhanced Linux. Vendor certification strategies can be misleading to laypersons. A common strategy exploits the layperson's overemphasis of EAL level with over certification, such as certifying an EAL 3 protection profile (like CAPP) to elevated levels, like EAL 4 or EAL 5. Another is adding and certifying MLS support features (such as role based access control protection profile (RBACPP) and labeled security protection profile (LSPP)) to a kernel that is not evaluated to an MLS capable protection profile. Those types of features are services run on the kernel and depend on the kernel to protect them from corruption and subversion. If the kernel is not evaluated to an MLS capable protection profile, MLS features cannot be trusted regardless of how impressive the demonstration looks. It is particularly noteworthy that CAPP is specifically not an MLS capable profile as it specifically excludes self protection capabilities critical for MLS. General Dynamics offers PitBull, a trusted, MLS operating system. PitBull is currently offered only as an enhanced version of Red Hat Enterprise Linux, but earlier versions existed for Sun Microsystems Solaris, IBM AIX, and SVR4 Unix. PitBull provides a Bell LaPadula security mechanism, a Biba integrity mechanism, a privilege replacement for superuser, and many other features. PitBull has the security base for General Dynamics' Trusted Network Environment (TNE) product since 2009. TNE enables Multilevel information sharing and access for users in the Department of Defense and Intelligence communities operating a varying classification levels. It's also the foundation for the Multilevel coalition sharing environment, the Battlefield Information Collection and Exploitation Systems Extended (BICES X). Sun Microsystems, now Oracle Corporation, offers Solaris Trusted Extensions as an integrated feature of the commercial OSs Solaris and OpenSolaris. In addition to the controlled access protection profile (CAPP), and role based access control (RBAC) protection profiles, Trusted Extensions have also been certified at EAL4 to the labeled security protection profile (LSPP). The security target includes both desktop and network functionality. LSPP mandates that users are not authorized to override the labeling policies enforced by the kernel and X Window System (X11 server). The evaluation does not include a covert channel analysis. Because these certifications depend on CAPP, no Common Criteria certifications suggest this product is trustworthy for MLS. BAE Systems offers XTS 400, a commercial system that supports MLS at what the vendor claims is "high assurance". Predecessor products (including the XTS 300) were evaluated at the TCSEC B3 level, which is MLS capable. The XTS 400 has been evaluated under the Common Criteria at EAL5+ against the CAPP and LSPP protection profiles. CAPP and LSPP are both EAL3 protection profiles that are not inherently MLS capable, but the security target for the Common Criteria evaluation of this product contains an enriched set of security functions that provide MLS capability.

Проблематические области

Санитаризация является проблемной областью для систем MLS. Системы, реализующие ограничения MLS, такие как определенные моделью Белла-ЛаПадулы, допускают обмен данными только в тех случаях, когда это явно не нарушает ограничения безопасности. Пользователи с более низким уровнем допуска могут легко делиться своей работой с пользователями с более высоким уровнем допуска, но не наоборот. Не существует эффективного и надежного механизма, позволяющего пользователю с уровнем "Совершенно секретно" отредактировать файл с уровнем "Совершенно секретно", удалить всю информацию с уровнем "Совершенно секретно" и затем передать его пользователям с уровнем "Секретно" или ниже. На практике системы MLS обходят эту проблему, используя привилегированные функции, позволяющие доверенному пользователю обходить механизм MLS и изменять классификацию безопасности файла. Однако этот подход ненадежен. Скрытые каналы представляют собой еще одну проблему для систем MLS. Чтобы система MLS идеально сохраняла секреты, не должно быть никакой возможности для процесса с уровнем "Совершенно секретно" передавать сигналы любого рода процессу с уровнем "Секретно" или ниже. Это включает в себя побочные эффекты, такие как изменения доступной памяти или дискового пространства, или изменения времени выполнения процесса. Когда процесс использует такой побочный эффект для передачи данных, он использует скрытый канал. Закрыть все скрытые каналы в практической вычислительной системе крайне сложно, и на практике это может быть невозможно. Сам процесс выявления всех скрытых каналов является сложной задачей. Большинство коммерчески доступных систем MLS не пытаются закрыть все скрытые каналы, хотя это делает их непрактичными для использования в приложениях с высокими требованиями к безопасности. Обход является проблематичным, когда он используется для обработки объекта высокого уровня, как если бы он был доверенным в рамках MLS. Типичный пример – извлечение данных из объекта высокого уровня с уровнем "Секретно" для отправки в неклассифицированное место назначения, со ссылкой на определенные свойства данных в качестве надежного доказательства того, что они "фактически" неклассифицированы (например, "строгий" формат). Система высокого уровня не может гарантировать сохранение каких-либо надежных доказательств, и в результате открывается явный канал передачи данных, который невозможно безопасно контролировать. Обход может быть рискованным, поскольку, в отличие от узкополосных скрытых каналов, которые сложно эксплуатировать, обход может представлять собой большую, легко используемую явную утечку в системе. Обход часто возникает из-за того, что архитекторы систем не учитывают безопасность при проектировании системы, а затем пытаются добавить функции безопасности уже после завершения разработки. В такой ситуации обход может показаться единственным (простым) способом заставить систему работать. Предлагаются (и утверждаются!) некоторые псевдобезопасные схемы, которые проверяют содержимое данных, прошедших обход, в тщетной попытке установить, что они не содержат секретов. Это невозможно без доверия к каким-либо характеристикам данных, таким как их формат, что противоречит предположению о том, что источник не может гарантировать сохранение характеристик исходных данных. Надежный "безопасный обход" – это миф, как и так называемый "Высокоассистентный защитник" (HAG), который прозрачно реализует обход. Риски, связанные с этим, давно признаны; существующие решения в конечном итоге являются процедурными, а не техническими. Невозможно с уверенностью узнать, какой объем классифицированной информации выводится из наших систем путем эксплуатации обхода.

Sanitization is a problem area for MLS systems. Systems that implement MLS restrictions, like those defined by Bell–LaPadula model, only allow sharing when it obviously does not violate security restrictions. Users with lower clearances can easily share their work with users holding higher clearances, but not vice versa. There is no efficient, reliable mechanism by which a Top Secret user can edit a Top Secret file, remove all Top Secret information, and then deliver it to users with Secret or lower clearances. In practice, MLS systems circumvent this problem via privileged functions that allow a trustworthy user to bypass the MLS mechanism and change a file's security classification. However, the technique is not reliable. Covert channels pose another problem for MLS systems. For an MLS system to keep secrets perfectly, there must be no possible way for a Top Secret process to transmit signals of any kind to a Secret or lower process. This includes side effects such as changes in available memory or disk space, or changes in process timing. When a process exploits such a side effect to transmit data, it is exploiting a covert channel. It is extremely difficult to close all covert channels in a practical computing system, and it may be impossible in practice. The process of identifying all covert channels is a challenging one by itself. Most commercially available MLS systems do not attempt to close all covert channels, even though this makes it impractical to use them in high security applications. Bypass is problematic when introduced as a means to treat a system high object as if it were MLS trusted. A common example is to extract data from a secret system high object to be sent to an unclassified destination, citing some property of the data as trusted evidence that it is 'really' unclassified (e. g. 'strict' format). A system high system cannot be trusted to preserve any trusted evidence, and the result is that an overt data path is opened with no logical way to securely mediate it. Bypass can be risky because, unlike narrow bandwidth covert channels that are difficult to exploit, bypass can present a large, easily exploitable overt leak in the system. Bypass often arises out of failure to use trusted operating environments to maintain continuous separation of security domains all the way back to their origin. When that origin lies outside the system boundary, it may not be possible to validate the trusted separation to the origin. In that case, the risk of bypass can be unavoidable if the flow truly is essential. A common example of unavoidable bypass is a subject system that is required to accept secret IP packets from an untrusted source, encrypt the secret userdata and not the header and deposit the result to an untrusted network. The source lies outside the sphere of influence of the subject system. Although the source is untrusted (e. g. system high) it is being trusted as if it were MLS because it provides packets that have unclassified headers and secret plaintext userdata, an MLS data construct. Since the source is untrusted, it could be corrupt and place secrets in the unclassified packet header. The corrupted packet headers could be nonsense but it is impossible for the subject system to determine that with any reasonable reliability. The packet userdata is cryptographically well protected but the packet header can contain readable secrets. If the corrupted packets are passed to an untrusted network by the subject system they may not be routable but some cooperating corrupt process in the network could grab the packets and acknowledge them and the subject system may not detect the leak. This can be a large overt leak that is hard to detect. Viewing classified packets with unclassified headers as system high structures instead of the MLS structures they really are presents a very common but serious threat. Most bypass is avoidable. Avoidable bypass often results when system architects design a system before correctly considering security, then attempt to apply security after the fact as add on functions. In that situation, bypass appears to be the only (easy) way to make the system work. Some pseudo secure schemes are proposed (and approved!) that examine the contents of the bypassed data in a vain attempt to establish that bypassed data contains no secrets. This is not possible without trusting something about the data such as its format, which is contrary to the assumption that the source is not trusted to preserve any characteristics of the source data. Assured "secure bypass" is a myth, just as a so called High Assurance Guard (HAG) that transparently implements bypass. The risk these introduce has long been acknowledged; extant solutions are ultimately procedural, rather than technical. There is no way to know with certainty how much classified information is taken from our systems by exploitation of bypass.

Дебаты: "Нет такого понятия, как МЛС"

Некоторые непрофессионалы проектируют защищенные вычислительные системы и приходят к выводу, что MLS не существует. Объяснение может заключаться в сокращении числа экспертов в области COMPUSEC и перегруженности термина MLS двумя различными значениями/применениями. Эти два применения: MLS как вычислительная среда и MLS как функциональность. Убеждение в несуществовании MLS основано на отсутствии сертифицированных продуктов, работающих в среде или режиме MLS, и, следовательно, на отсутствии MLS как функциональности. Однако одно не подразумевает другое. Многие системы работают в среде, содержащей данные с разными уровнями безопасности и, следовательно, являются MLS согласно теореме промежуточных значений компьютерной безопасности (CS IVT). Последствия этой путаницы более серьезны. Операционные системы, базы данных и сети, сертифицированные АНБ для работы в режиме MLS, существуют с 1970-х годов, и продукты MLS продолжают разрабатываться, продаваться и внедряться. Неспециалисты часто приходят к выводу, что признание работы системы в среде MLS (ориентированное на среду значение MLS) означает попадание в ситуацию, когда необходимо решить проблему, для которой нет решения MLS (ориентированное на функциональность значение MLS). MLS обманчиво сложна, и тот факт, что простые решения не очевидны, не оправдывает вывод об их отсутствии. Это может привести к критическому невежеству в области COMPUSEC, которое проявляется в шепоте о том, что "о MLS нельзя говорить" и "MLS не существует". Эти схемы отрицания MLS меняются настолько быстро, что их невозможно устранить. Вместо этого важно прояснить различие между средой MLS и поддержкой MLS (MLS capable). MLS как среда безопасности или режим безопасности: сообщество, пользователи которого имеют различные уровни доступа, может рассматривать MLS как возможность обмена данными: пользователи могут обмениваться информацией с получателями, уровень доступа которых позволяет им получать эту информацию. Система работает в режиме MLS, когда она имеет (или может иметь) подключение к пункту назначения, уровень доступа которого ниже, чем у любых данных, содержащихся в системе MLS. Это формализовано в CS IVT. Определение режима безопасности системы полностью зависит от среды безопасности системы: классификации содержащихся в ней данных, уровня доступа тех, кто может получить прямой или косвенный доступ к системе или ее результатам, а также подключений и портов системы к другим системам. Режим безопасности не зависит от функциональности, хотя система не должна работать в режиме, которому она не соответствует по уровню доверия. MLS как функциональность: разработчики продуктов или систем, предназначенных для обмена данными MLS, склонны понимать это как возможность применения ограничений обмена данными или политики безопасности, например, механизмов, реализующих модель Bell–LaPadula. Система поддерживает MLS, если можно продемонстрировать надежную реализацию политики безопасности. Первоначальное использование термина MLS относилось к среде безопасности или режиму. Одним из решений этой путаницы является сохранение первоначального определения MLS и уточнение, что имеется в виду поддержка MLS (MLS capable), когда используется этот контекст.

Some laypersons are designing secure computing systems and drawing the conclusion that MLS does not exist. An explanation could be that there is a decline in COMPUSEC experts and the MLS term has been overloaded by two different meanings / uses. These two uses are: MLS as a processing environment vs MLS as a capability. The belief that MLS is non existent is based on the belief that there are no products certified to operate in an MLS environment or mode and that therefore MLS as a capability does not exist. One does not imply the other. Many systems operate in an environment containing data that has unequal security levels and therefore is MLS by the Computer Security Intermediate Value Theorem (CS IVT). The consequence of this confusion runs deeper. NSA certified MLS operating systems, databases, and networks have existed in operational mode since the 1970s and that MLS products are continuing to be built, marketed, and deployed. Laypersons often conclude that to admit that a system operates in an MLS environment (environment centric meaning of MLS) is to be backed into the perceived corner of having a problem with no MLS solution (capability centric meaning of MLS). MLS is deceptively complex and just because simple solutions are not obvious does not justify a conclusion that they do not exist. This can lead to a crippling ignorance about COMPUSEC that manifests itself as whispers that "one cannot talk about MLS," and "There's no such thing as MLS." These MLS denial schemes change so rapidly that they cannot be addressed. Instead, it is important to clarify the distinction between MLS environment and MLS capable. MLS as a security environment or security mode: A community whose users have differing security clearances may perceive MLS as a data sharing capability: users can share information with recipients whose clearance allows receipt of that information. A system is operating in MLS Mode when it has (or could have) connectivity to a destination that is cleared to a lower security level than any of the data the MLS system contains. This is formalized in the CS IVT. Determination of security mode of a system depends entirely on the system's security environment; the classification of data it contains, the clearance of those who can get direct or indirect access to the system or its outputs or signals, and the system's connectivity and ports to other systems. Security mode is independent of capabilities, although a system should not be operated in a mode for which it is not worthy of trust. MLS as a capability: Developers of products or systems intended to allow MLS data sharing tend to loosely perceive it in terms of a capability to enforce data sharing restrictions or a security policy, like mechanisms that enforce the Bell–LaPadula model. A system is MLS capable if it can be shown to robustly implement a security policy. The original use of the term MLS applied to the security environment, or mode. One solution to this confusion is to retain the original definition of MLS and be specific about MLS capable when that context is used.

Архитектура MILS

Multiple Independent Levels of Security (MILS) — это архитектура, решающая задачу разделения доменов в рамках MLS. Следует отметить, что UCDMO (главный орган правительства США по системам междоменного и многоуровневого доступа) ввел термин «Междоменный доступ» как категорию в своей базовой линии аккредитованных систем Министерства обороны и разведывательного сообщества, и эту категорию можно рассматривать как по существу аналогичную MILS. Модели безопасности, такие как модель Биба (для целостности) и модель Белла-ЛаПадулы (для конфиденциальности), допускают односторонний поток данных между определенными доменами безопасности, которые в противном случае считаются изолированными. MILS обеспечивает изоляцию, лежащую в основе MLS, но не рассматривает контролируемое взаимодействие между доменами, рассматриваемое вышеупомянутыми моделями. Доверенные каналы, соответствующие требованиям безопасности, могут связывать домены MILS для поддержки расширенной функциональности MLS. Подход MILS реализует стратегию, основанную на более раннем термине MSL (multiple single level – множественный одинарный уровень), который изолирует каждый уровень информации в своей собственной среде одинарного уровня (System High). Строгая коммуникация процессов и изоляция, обеспечиваемые MILS, могут быть более полезны для программных приложений, требующих ультравысокой надежности, чем MLS. MILS, в частности, не учитывает иерархическую структуру, воплощенную в понятии уровней безопасности. Это требует добавления специальных приложений импорта/экспорта между доменами, каждое из которых должно быть соответствующим образом аккредитовано. Таким образом, MILS было бы точнее назвать Multiple Independent Domains of Security (эмуляция MLS на MILS потребует аналогичного набора аккредитованных приложений для приложений MLS). Отказываясь от взаимодействия между уровнями «из коробки», соответствующего иерархическим отношениям Белла-ЛаПадулы, MILS (почти обманчиво) прост в первоначальной реализации, но требует существенных дополнительных приложений импорта/экспорта для достижения богатства и гибкости, ожидаемых от практических приложений MLS. При сравнении MILS и MLS следует учитывать, является ли аккредитация набора более простых экспортных приложений более достижимой, чем аккредитация одного, более сложного ядра MLS. Этот вопрос частично зависит от объема взаимодействия импорта и экспорта, необходимого заинтересованным сторонам. В пользу MILS говорит возможность того, что не всем приложениям экспорта потребуется максимальная гарантия.

Multiple Independent Levels of Security (MILS) is an architecture that addresses the domain separation component of MLS. Note that UCDMO (the US government lead for cross domain and multilevel systems) created a term Cross Domain Access as a category in its baseline of DoD and Intelligence Community accredited systems, and this category can be seen as essentially analogous to MILS. Security models such as the Biba model (for integrity) and the Bell–LaPadula model (for confidentiality) allow one way flow between certain security domains that are otherwise assumed to be isolated. MILS addresses the isolation underlying MLS without addressing the controlled interaction between the domains addressed by the above models. Trusted security compliant channels mentioned above can link MILS domains to support more MLS functionality. The MILS approach pursues a strategy characterized by an older term, MSL (multiple single level), that isolates each level of information within its own single level environment (System High). The rigid process communication and isolation offered by MILS may be more useful to ultra high reliability software applications than MLS. MILS notably does not address the hierarchical structure that is embodied by the notion of security levels. This requires the addition of specific import/export applications between domains each of which needs to be accredited appropriately. As such, MILS might be better called Multiple Independent Domains of Security (MLS emulation on MILS would require a similar set of accredited applications for the MLS applications). By declining to address out of the box interaction among levels consistent with the hierarchical relations of Bell La Padula, MILS is (almost deceptively) simple to implement initially but needs non trivial supplementary import/export applications to achieve the richness and flexibility expected by practical MLS applications. Any MILS/MLS comparison should consider if the accreditation of a set of simpler export applications is more achievable than accreditation of one, more complex MLS kernel. This question depends in part on the extent of the import/export interactions that the stakeholders require. In favour of MILS is the possibility that not all the export applications will require maximal assurance.

Системы MSL

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

Приложения

Инфраструктура, такая как доверенные операционные системы, является важным компонентом систем MLS, но для соответствия критериям, установленным в определении MLS согласно CNSSI 4009 (перефразированном в начале этой статьи), система должна предоставлять пользовательский интерфейс, позволяющий пользователю получать доступ и обрабатывать контент на различных уровнях классификации из одной системы. В 2009 году UCDMO организовала отдельную секцию, посвященную MLS, на симпозиуме NSA по информационной безопасности, где были представлены несколько аккредитованных (внедренных в производство) и перспективных систем MLS. Обратите внимание на использование MLS в SELinux. Существует несколько баз данных, классифицированных как системы MLS. Oracle предлагает продукт Oracle Label Security (OLS), который реализует обязательный контроль доступа, как правило, путем добавления столбца "метка" в каждую таблицу базы данных Oracle. OLS внедряется в INSCOM Армии США в качестве основы базы данных разведданных "из всех источников", охватывающей сети JWICS и SIPRNet. Ведется разработка маркированной версии PostgreSQL, а также существуют более ранние реализации маркированных баз данных, такие как Trusted Rubix. Эти системы баз данных MLS обеспечивают единую серверную часть для контента с различными метками, но не решают проблему обработки пользователями контента на нескольких уровнях секретности в одной системе при соблюдении обязательного контроля доступа. Существует также ряд пользовательских приложений MLS. Еще одна возможность MLS, включенная в базовую конфигурацию UCDMO, называется MLChat – это чат-сервер, работающий на операционной системе XTS 400, разработанной Военно-морской исследовательской лабораторией США. Поскольку контент от пользователей из разных доменов проходит через сервер MLChat, используется фильтрация ненормативной лексики для защиты секретной информации, и ведутся дискуссии о том, является ли это действительно системой MLS или скорее формой защиты данных при междоменном обмене. Обязательный контроль доступа обеспечивается комбинацией XTS 400 и механизмов, специфичных для приложений. Joint Cross Domain eXchange (JCDX) – еще один пример возможности MLS, включенной в базовую конфигурацию UCDMO. JCDX – единственная система командования, управления, связи, компьютеров и разведки (C4I), аккредитованная Министерством обороны (DoD) и Агентством военной разведки (DIA), обеспечивающая разведывательную и предупредительную поддержку в режиме, близком к реальному времени, для оперативных театров и передовых тактических командиров. Архитектура JCDX тесно интегрирована с высоконадежной защищенной операционной системой четвертого уровня защиты (PL4), использующей маркировку данных для распространения информации о деятельности сил и потенциальных террористических угрозах в мировом океане и вокруг него. Она установлена в США и странах-партнерах, где может предоставлять данные от уровня "Совершенно секретно/SCI" до уровня "Секретно для распространения", все на одной платформе. Приложения MLS, которые в настоящее время не входят в базовую конфигурацию UCDMO, включают несколько приложений от BlueSpace. BlueSpace предлагает ряд приложений MLS, включая почтовый клиент MLS, приложение для поиска MLS и систему управления и контроля MLS (C2). BlueSpace использует стратегию промежуточного программного обеспечения, чтобы обеспечить платформенную независимость своих приложений, оркеструя единый пользовательский интерфейс через несколько экземпляров ОС Windows (виртуализированных или удаленных сеансов терминалов). Военно-морская исследовательская лаборатория США также разработала многоуровневую веб-платформу под названием MLWeb, которая интегрирует Ruby on Rails с многоуровневой базой данных на основе SQLite3.

Infrastructure such as trusted operating systems are an important component of MLS systems, but in order to fulfill the criteria required under the definition of MLS by CNSSI 4009 (paraphrased at the start of this article), the system must provide a user interface that is capable of allowing a user to access and process content at multiple classification levels from one system. The UCDMO ran a track specifically focused on MLS at the NSA Information Assurance Symposium in 2009, in which it highlighted several accredited (in production) and emergent MLS systems. Note the use of MLS in SELinux. There are several databases classified as MLS systems. Oracle has a product named Oracle Label Security (OLS) that implements mandatory access controls typically by adding a 'label' column to each table in an Oracle database. OLS is being deployed at the US Army INSCOM as the foundation of an "all source" intelligence database spanning the JWICS and SIPRNet networks. There is a project to create a labeled version of PostgreSQL, and there are also older labeled database implementations such as Trusted Rubix. These MLS database systems provide a unified back end system for content spanning multiple labels, but they do not resolve the challenge of having users process content at multiple security levels in one system while enforcing mandatory access controls. There are also several MLS end user applications. The other MLS capability currently on the UCDMO baseline is called MLChat , and it is a chat server that runs on the XTS 400 operating system it was created by the US Naval Research Laboratory. Given that content from users at different domains passes through the MLChat server, dirty word scanning is employed to protect classified content, and there has been some debate about if this is truly an MLS system or more a form of cross domain transfer data guard. Mandatory access controls are maintained by a combination of XTS 400 and application specific mechanisms. Joint Cross Domain eXchange (JCDX) is another example of an MLS capability currently on the UCDMO baseline. JCDX is the only Department of Defense (DoD), Defense Intelligence Agency (DIA) accredited Multilevel Security (MLS) Command, Control, Communication, Computers and Intelligence (C4I) system that provides near real time intelligence and warning support to theater and forward deployed tactical commanders. The JCDX architecture is comprehensively integrated with a high assurance Protection Level Four (PL4) secure operating system, utilizing data labeling to disseminate near real time data information on force activities and potential terrorist threats on and around the world's oceans. It is installed at locations in United States and Allied partner countries where it is capable of providing data from Top Secret/SCI down to Secret Releasable levels, all on a single platform. MLS applications not currently part of the UCDMO baseline include several applications from BlueSpace. BlueSpace has several MLS applications, including an MLS email client, an MLS search application and an MLS C2 system. BlueSpace leverages a middleware strategy to enable its applications to be platform neutral, orchestrating one user interface across multiple Windows OS instances (virtualized or remote terminal sessions). The US Naval Research Laboratory has also implemented a multilevel web application framework called MLWeb which integrates the Ruby on Rails framework with a multilevel database based on SQLite3.

Тенденции

Возможно, самое значительное изменение, происходящее сегодня в области многоуровневой безопасности, – это сближение MLS с технологией виртуализации. Все большее число доверенных операционных систем отказывается от маркировки файлов и процессов, переходя к использованию UNIX-контейнеров или виртуальных машин. Примеры включают зоны в Solaris 10 TX, гипервизор "padded cell" в системах, таких как платформа Integrity от Green Hills и XenClient XT от Citrix. Платформа высокой надежности, разработанная NSA и реализованная в доверенной среде виртуализации (TVE) компании General Dynamics, является еще одним примером – она использует SELinux в качестве ядра и может поддерживать MLS-приложения, охватывающие несколько доменов.