PD-0122: Description of Logical and Physical Boundaries

This decision represents a long-term technical decision based on an OD, and may not be the same as the final results of the source OD. With respect to published criteria documentation and scheme documents, it provides suggested guidance on evaluation direction, but is not authoritative. Authoritative decisions are provided through the published criteria documents and published scheme and international interpretations thereof. With respect to published PPs, PDs are authoritative corrections to the PP, based on input from the PP author (if available), that are in force until the publication of the next revision of that PP.

Issue

In many STs, the Logical and Physical Boundary sections are less than useful. Often, what is presented is merely a repetition of the material that is already in both the TOE Description and the TSS Sections. How do we make these sections useful?

Resolution

The goal of the "Boundary" sections in an ST or PP is to define a boundary; that is, to define at the physical or logical level what is in the TSF or TOE, and what is excluded from the TSF or TOE. This alerts the reader to what was excluded from analysis during evaluation and must, therefore, be addressed by the integrator, DAA, etc. While this is clarified in CC v3.0, this clarification is equally applicable to CC v2.1/v2.2:

The TOE description discusses the physical scope and boundaries of the TOE: the hardware, firmware and software parts that constitute the TOE at a level of detail that is sufficient to give the reader a general understanding of those parts. The TOE description should also list all guidance that is part of the TOE.

The TOE description should also discuss the logical scope and boundaries of the TOE: the logical security features offered by the TOE at a level of detail that is sufficient to give the reader a general understanding of those features.

An important property of the physical and logical descriptions is that they describe the boundaries of the TOE in such a way that there remains no doubt on whether a certain part or feature is in the TOE or whether this is outside the TOE. This is especially important when the TOE is intertwined with and cannot be easily separated from non-TOE entities.

Support

In the ST, the focus needs to be on the end consumer who might be reading the ST. This consumer wants to know what was evaluated, both in terms of the physical chunks (i.e., that which can be ordered and delivered) and the logical function (the processing provided). The problem is that there is a variety of "consumers" for the ST: acquisition authorities, certifiers, prime contractors, administrators, integrators, and potential end users. However, it is clear that a simple repetition of the security functions of the TOE, which is contained elsewhere in the TOE, is not useful. Similarly, a simple statement of system requirements is insufficient.

The key element in developing these descriptions is that there be no doubt regarding what side of the TOE/TSF a particular hardware component, software component, or service lies: Is a component in the TOE or the IT environment? Is a service provided by the TSF portion of the TOE, outside the TSF but in the TOE and thus unevaluated, or provided by the environment? This means that the description of the services provided by the TOE must not only state what *is* in the TOE, but must also state what *isn't* in the TOE. In other words, if there are services that one might normally expect to be included as part of the TOE given its nature or function, but that are excluded from the evaluated configuration, this must be noted here.

Some examples may make this clearer:

• Consider the following Physical Boundary description:

  The product has a standards-compliant layered architecture, supports several tool sets that facilitate the separation of process and data, providing functionality for the development of data processing applications. It runs on Intel platforms using the Linux operating system.

  This really doesn't say anything about the boundary: it provides no specifics, no clarity as to the boundary. The following would be a better way to write it:

  The TOE is an application that runs on PC platforms (which are in the IT environment) with a minimum of: 1GHz Intel or AMD CPU, 512Mb main memory, 100 Gb hard drive, CD-ROM drive, and two 100Mbps NICs. Mouse, keyboard, and monitor are not necessary though some sort of remote access program will be needed. It is shipped on a single CDROM and installed on the system hard drive of any Red Hat operating system since V8, Suse Linux since V4, and Turbo Linux since V4. An SSH package is required. The operating system, any remote access program, and the SSH package are in the IT environment.

  This is good because it provides the needed specific: relevant characteristics of the hardware. Version numbers. Packages required. It also makes clear what is in the IT environment.

• Consider the following Logical Boundary description:

  The TOE provides the following Common Criteria security functions in the areas of Security Audit, User Data Protection, Identification and Authentication, Security Management, and Protection of the TOE Security Functions (TSF).

  Auditing provides an electronic trail of security-relevant events. The audit server supplies these services.

  (and so on)

  The following would be a better way to write this:

  The TOE consists of a number of distributed applications, each running on top of a previously evaluated operating system and hardware (which is in the IT environment). These applications include a database that contains TSF data that is used to control access to users and an audit server that collects transmitted audit data. The database includes a facility to interact with an external identification and authentication server that is in the environment. The TOE also includes a webserver that provides management functionality, and an implementation of SSL protocols to support that functionality, interfacing to the database, communication with the audit and external identification and authentication servers. The TOE uses the protection capabilities provided by the underlying evaluated OS to protect itself.

  The database includes the ability to encrypt stored data. This facility is not part of the TSF.

  The operating system, which is in the IT environment, provides the network stack from the TCP/UDP level down. Components used by users to access the web server, such as web browsers and external systems, are likewise in the IT environment. The database implemented by the TOE and the audit server uses the file system and protection mechanisms provided by the underlying operating system.

  This is good because it make it clear what functions are part of the main TOE, what are provided by servers in the TOE, and what components are in the environment.

As these examples show, the physical discussion needs to be specific. The logical discussion should not be at the level of functions as the ST sees them (i.e., Data Protection, Identification and Authentication), but in the way the user sees the services (Database, Agents, Key Managers). By having this focus, the section becomes useful and not merely a regurgitation of the functions of the TOE.

The sections on logical and physical boundary should identify the set of functional and hardware elements that exist in the deployed product and/or the evaluated configuration, and must specify all of the elements that instantiate the TOE (i.e., are required to make it function as specified) and that completely encompass the TOE (i.e., there are guaranteed to be no TOE elements outside the logical and physical boundary). This should include any external hardware dependencies, while making it clear what is inside the TOE boundary and what is outside the TOE boundary. The logical description must do the same for the major functional units of the TOE, thereby making it clear what is in the TOE, and what is outside the TOE but used by the TOE.

Modification History:

2005-08-23

PD Created. [August 2005 ODRB Agenda Item 4.b.i]

2005-11-07

Based on comments from the cc-cmt discussion, clarified how to express the logical and physical boundaries. (November 2005 ODRB Agenda Item 4.d.ii)

References:

• None

Related NIs:

• None

Related CCIMB-INTERPs:

• None

Source OD: 0158