Misplaced Pages

#151848

66-406: To achieve a particular EAL, the computer system must meet specific assurance requirements . Most of these requirements involve design documentation, design analysis, functional testing, or penetration testing. The higher EALs involve more detailed documentation, analysis, and testing than the lower ones. Achieving a higher EAL certification generally costs more money and takes more time than achieving

132-516: 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

198-459: 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

264-646: 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

330-519: 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

396-408: 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. The original use of the term MLS applied to

462-450: A higher EAL means nothing more, or less, than that the evaluation completed a more stringent set of quality assurance requirements. It is often assumed that a system that achieves a higher EAL will provide its security features more reliably (and the required third-party analysis and testing performed by security experts is reasonable evidence in this direction), but there is little or no published evidence to support that assumption. In 2006,

528-496: 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

594-515: A lower one. The EAL number assigned to a certified system indicates that the system completed all requirements for that level. Although every product and system must fulfill the same assurance requirements to achieve a particular level, they do not have to fulfill the same functional requirements. The functional features for each certified product are established in the Security Target document tailored for that product's evaluation. Therefore,

660-426: A manner consistent with its documentation, and that it provides useful protection against identified threats. EAL2 requires the cooperation of the developer in terms of the delivery of design information and test results, but should not demand more effort on the part of the developer than is consistent with good commercial practice. As such it should not require a substantially increased investment of cost or time. EAL2

726-471: A minimum of EAL4. Examples with active Certificate include SUSE Linux Enterprise Server 15 (EAL 4+). Examples with expired Certificate are Trusted Solaris , Solaris 10 Release 11/06 Trusted Extensions , an early version of the XTS-400 , VMware ESXi version 4.1, 3.5, 4.0, AIX 4.3, AIX 5L, AIX 6, AIX7, Red Hat 6.2 & SUSE Linux Enterprise Server 11 (EAL 4+). vSphere 5.5 Update 2 did not achieve EAL4+ level it

SECTION 10

#1732895215152

792-591: A multilevel web application framework called MLWeb which integrates the Ruby on Rails framework with a multilevel database based on SQLite3 . Perhaps the greatest change going on in the multilevel security arena today is the convergence of MLS with virtualization. An increasing number of trusted operating systems are moving away from labeling files and processes, and are instead moving towards UNIX containers or virtual machines . Examples include zones in Solaris 10 TX , and

858-499: A product with a higher EAL is not necessarily "more secure" in a particular application than one with a lower EAL, since they may have very different lists of functional features in their Security Targets. A product's fitness for a particular security application depends on how well the features listed in the product's Security Target fulfill the application's security requirements. If the Security Targets for two products both contain

924-472: A separate untrusted domain. The absence of a medium of communication between the domains assures no interaction is possible. The mechanism for this isolation is usually physical separation in separate computers. This is often used to support applications or operating systems which have no possibility of supporting MLS such as Microsoft Windows . Infrastructure such as trusted operating systems are an important component of MLS systems, but in order to fulfill

990-560: 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

1056-529: 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

1122-583: 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

1188-444: 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

1254-486: 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

1320-468: 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

1386-514: Is applicable in those circumstances where developers or users require a moderate level of independently assured security, and require a thorough investigation of the TOE and its development without substantial re-engineering. EAL4 permits a developer to gain maximum assurance from positive security engineering based on good commercial development practices which, though rigorous, do not require substantial specialist knowledge, skills, and other resources. EAL4

SECTION 20

#1732895215152

1452-457: 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

1518-491: 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

1584-403: 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. There is another way of solving such problems known as multiple single-level . Each security level is isolated in

1650-545: 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

1716-483: Is no way to know with certainty how much classified information is taken from our systems by exploitation of bypass. 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

1782-447: 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

1848-522: Is the application of a computer system to process information with incompatible classifications (i.e., at different security levels), permit access by users with different security clearances and needs-to-know , and prevent users from obtaining access to information for which they lack authorization. There are two contexts for the use of multilevel security. This distinction is important because systems that need to be trusted are not necessarily trustworthy. An MLS operating environment often requires

1914-908: Is the highest level at which it is likely to be economically feasible to retrofit to an existing product line. EAL4 is therefore applicable in those circumstances where developers or users require a moderate to high level of independently assured security in conventional commodity TOEs and are prepared to incur additional security-specific engineering costs. Commercial operating systems that provide conventional, user-based security features are typically evaluated at EAL4. Examples with expired Certificate are AIX , HP-UX , Oracle Linux , NetWare , Solaris , SUSE Linux Enterprise Server 9 , SUSE Linux Enterprise Server 10 , Red Hat Enterprise Linux 5 , Windows 2000 Service Pack 3, Windows 2003 , Windows XP , Windows Vista , Windows 7 , Windows Server 2008 R2 , z/OS version 2.1 and z/VM version 6.3. Operating systems that provide multilevel security are evaluated at

1980-467: Is therefore applicable in those circumstances where developers or users require a low to moderate level of independently assured security in the absence of ready availability of the complete development record. Such a situation may arise when securing legacy systems. EAL3 permits a conscientious developer to gain maximum assurance from positive security engineering at the design stage without substantial alteration of existing sound development practices. EAL3

2046-415: Is therefore applicable to the development of security TOEs for application in high risk situations where the value of the protected assets justifies the additional costs. Green Hills Software's INTEGRITY-178B RTOS has been certified to EAL6 augmented. EAL7 is applicable to the development of security TOEs for application in extremely high risk situations and/or where the high value of the assets justifies

Evaluation Assurance Level - Misplaced Pages Continue

2112-677: 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

2178-563: The Security Target ( ST ) as an "implementation-dependent statement of security needs for a specific identified Target of Evaluation ( TOE )". In other words, the ST defines boundary and specifies the details of the TOE. In a product evaluation process according to the CC the ST document is provided by the vendor of the product. An ST defines information assurance security and functional requirements for

2244-423: 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

2310-753: 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. 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

2376-655: 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

2442-616: 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

2508-574: The EAL5 requirements, relative to rigorous development without the application of specialized techniques, will not be large. EAL5 is therefore applicable in those circumstances where developers or users require a high level of independently assured security in a planned development and require a rigorous development approach without incurring unreasonable costs attributable to specialist security engineering techniques. Numerous smart card devices have been evaluated at EAL5, as have multilevel secure devices such as

2574-400: The TOE (Target of Evaluation) as made available to the customer, including independent testing against a specification, and an examination of the guidance documentation provided. It is intended that an EAL1 evaluation could be successfully conducted without assistance from the developer of the TOE, and for minimal cost. An evaluation at this level should provide evidence that the TOE functions in

2640-477: The Tenix Interactive Link. XTS-400 (STOP 6) is a general-purpose operating system which has been evaluated at EAL5 augmented. LPAR on IBM System z is EAL5 Certified. EAL6 permits developers to gain high assurance from application of security engineering techniques to a rigorous development environment in order to produce a premium TOE for protecting high-value assets against significant risks. EAL6

2706-580: The UCDMO baseline is called MLChat Archived 2013-03-17 at the Wayback Machine , 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

Evaluation Assurance Level - Misplaced Pages Continue

2772-529: The US Government Accountability Office published a report on Common Criteria evaluations that summarized a range of costs and schedules reported for evaluations performed at levels EAL2 through EAL4. In the mid to late 1990s, vendors reported spending US$ 1 million and even US$ 2.5 million on evaluations comparable to EAL4. There have been no published reports of the cost of the various Microsoft Windows security evaluations. In some cases,

2838-399: 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

2904-468: 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,

2970-451: 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

3036-558: 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

3102-538: 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

3168-417: 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

3234-628: The depth and rigor of the security evaluation, usually in the form of supporting documentation and testing, that the product meets the SFRs. An ST contains some (but not very detailed) implementation-specific information that demonstrates how the product addresses the security requirements. It may refer to one or more Protection Profiles (PPs). In such a case, the ST must fulfill the generic security requirements given in each of these PPs, and may define further requirements. Multilevel security Multilevel security or multiple levels of security ( MLS )

3300-550: The evaluation may be augmented to include assurance requirements beyond the minimum required for a particular EAL. Officially this is indicated by following the EAL number with the word augmented and usually with a list of codes to indicate the additional requirements. As shorthand, vendors will often simply add a "plus" sign (as in EAL4+ ) to indicate the augmented requirements. The Common Criteria standards denote EALs as shown in this article:

3366-526: 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

SECTION 50

#1732895215152

3432-480: The given information system product, which is called the Target of Evaluation (TOE). An ST is a complete and rigorous description of a security problem in terms of TOE description, threats, assumptions, security objectives, security functional requirements (SFRs), security assurance requirements (SARs), and rationales. The SARs are typically given as a number 1 through 7 called Evaluation Assurance Level (EAL), indicating

3498-425: 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

3564-575: The higher costs. Practical application of EAL7 is currently limited to TOEs with tightly focused security functionality that is amenable to extensive formal analysis. The ProvenCore OS, developed by ProvenRun , has been certified to EAL7 in 2019 by the ANSSI . The Tenix Interactive Link Data Diode Device and the Fox-IT Fox Data Diode (one-way data communications device) claimed to have been evaluated at EAL7 augmented (EAL7+). Technically speaking,

3630-438: 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 ,

3696-452: 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

3762-467: The necessary security features, then the higher EAL should indicate the more trustworthy product for that application. EAL1 is applicable where some confidence in correct operation is required, but the threats to security are not viewed as serious. It will be of value where independent assurance is required support the contention that due care has been exercised with respect to the protection of personal or similar information. EAL1 provides an evaluation of

3828-442: The prefix "EAL" concatenated with a digit 1 through 7 (Examples: EAL1, EAL3, EAL5). In practice, some countries place a space between the prefix and the digit (EAL 1, EAL 3, EAL 5). The use of a plus sign to indicate augmentation is an informal shorthand used by product vendors (EAL4+ or EAL 4+). Security Target Common Criteria for Information Technology Security Evaluation, version 3.1 Part 1 (called CC 3.1 or CC) defines

3894-427: 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

3960-513: 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. 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

4026-413: 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

SECTION 60

#1732895215152

4092-426: 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

4158-424: 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

4224-579: 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

4290-408: Was an EAL2+ and certified on June 30, 2015. EAL5 permits a developer to gain maximum assurance from security engineering based upon rigorous commercial development practices supported by moderate application of specialist security engineering techniques. Such a TOE will probably be designed and developed with the intent of achieving EAL5 assurance. It is likely that the additional costs attributable to

4356-523: Was once thought to be a problem for these free MLS implementations for three reasons: 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

#151848