PD-0096: Custom Access Control Language for FDP_IFC and FDP_IFF

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

Is it appropriate to use FDP_IFC and FDP_IFF to describe a product that performs information flow control based on a custom access control language that can be manipulated by the administrator?

Many security products are moving toward providing a custom language to express policy, as opposed to using simple configuration tables. How much detail for such a custom language (syntax, semantics) is required to be included within the ST?

Resolution

It is acceptable to use FDP_IFC and FDP_IFF to describe specific policy details but, regardless of where/how the specifics are described, the ST must provide a description of the policy that the TOE enforces. This also includes cases where the policy is simply that the TOE will enforce the rules set forth in the specification language.

It should always be possible to describe this correctly, if abstractly, within the space allotted in the TSS section of a Security Target. The policy description should not require the precise semantics (e.g., an ST can describe a UNIX policy without attaching the man pages for chmod and chown), and in fact the details may obscure the overall policy. The details of semantics, which will be required for testing, will be found in the Functional Specification or Administrator Guide; they need not be in the ST. However, while the ST must describe the policy in general terms in the TSS section, it may include a reference to the rule specification language for more specific details.

In cases where the specifics of the policy being enforced depends upon the rules that are defined, it is not possible to express the rules in the ST under the FDP_IFC/IFF requirements. In such cases, it is sufficient to provide an explanation that the precise rules are settable. This explanation must also describe the capabilities of the syntax used to set the rules, although the specific syntax itself is not necessary. A reference to an external specification of the language is sufficient; the details need not be incorporated into the body of the ST.

For example, firewalls typically exhibit settable policies. The ST would explain this, but would also describe the characteristics that can be captured in the rules, such as source IP address, destination IP address, port numbers, protocols, header fields, data content, etc. and then reference the specification of the syntax and semantics of the language that is used to implement those rules. This is the sort of information that would be of interest to potential customers who are interested in whether a given product can meet their needs.

Modification History:

2004-08-12

Updated effective date to reflect the date the PD was issued. (August 2004 NIB 6.c.xiv)

References:

• CC v2.1 Part 2 Subclause 6.5 FDP_IFC
• CC v2.1 Part 2 Subclause 6.6 FDP_IFF

Related NIs:

• None

Related CCIMB-INTERPs:

• None

Source OD: 0216