PD-0126: Administrator-entered Code Used To Meet SFRs

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 permissible to claim conformance with a SFR that requires the administrator to explicitly enter code to enforce the SFR, copying that code from a provided manual, and then configure the TOE to enforce the corresponding code? More to the point, given that the CC specifically allows that a TOE can be installed, generated, and started by the TOE user, is there any requirement (other than perhaps misuse) limiting the extent or nature of guidance that must be followed in order to instantiate the TOE in its evaluated configuration?

Resolution

Administrator entry of TSF implementation code (as opposed to security configuration parameters) in a manner that does not permit assured verification that the entered code corresponds to the code under configuration management is not permitted. The distinction between code and configuration parameters is a subtle one: the TSF implementation (code) provides the logic and enforcement functions that support enforcement of policy; configuration parameters provide the parameters to that policy, or enable/disable execution of the implementing code.

Support

Administrators serve many functions in the establishment of the secure state of the TSF. They are responsible for receiving the delivered TOE, any installation and generation, and configuration of the TOE into its operating evaluated configuration. The installation and generation phases of this involve receiving the implementation representation (or a compiled implementation representation) and performing any necessary installation. This installation provides the executable code that has the logic and ability to enforce the SFRs. The administrator then configures the TOE with the specific parameters for the site: be these access control lists, firewall rulesets, user definitions, audit event selections, and other parameters used by the logic to make decisions.

With respect to these activities, a number of Common Criteria Requirements come into play:

• The ACM requirements require that the implementation representation be under configuration management. This means that changes to the implementation representation are controlled in accordance with the CM plan.

• The ADO requirements, depending on the level, may require that the administrator have the ability to verify the integrity of the delivered code.

• The AVA_MSU requirements require the administrator guidance to be reasonable, and that there be the ability to detect insecure states.

The Issue statement in this PD presents the situation where an Administrator is directed to enter code from a printed manual, and then enable execution of that code. It is the code entry that is of concern; enabling execution of existent code clearly falls under system configuration.

Code entry by an administrator from a printed manual is of concern for a number of reasons:

• Such code is not guaranteed to be under configuration management, at least as entered by the administrator.

• Code entry from a manual does not provide assurance of the integrity of the entered code, except by solely manual methods (visual comparison).

• Depending on the number of lines of code, it may be unreasonable to expect the administrator to accurately copy the information.

• Depending on the implementation, there may be no mechanism that permits detection of whether the code leaves the system in an insecure state. This is particularly true of logic that is being manually entered, as small typographical errors (for example, substituting a "<" for a ">") would be syntactically correct but insecure.

Some may argue that such code should be considered configuration parameters. This PD makes a distinction between the two as follows: code is logic that examines parameters, and based on those parameters makes and implements decisions that enforce policy. So, for example, code parses a firewall ruleset, examines the contents of packets, and based on packet contents and the rules, enforces access. Code does something similar for Access Control Lists. In the system access arena, it is code that is invoked when a user logs in, examines the number of failed logins, and based on a parameter, enforces whether access is permitted. This code is tested to make sure that parameters are interpreted correctly and logic enforced.

Another distinction between code and configuration parameters relates to its specificity. Code is generic: it provides logic that is independent of any specific installation. Configuration parameters are typically specific to an installation or use: firewall parameters have site-specific IP addresses, ACLs have site-specific users, auditing parameters are based on site-specific needs, authentication thresholds are based on site-specific risks.

Misuse Analysis plays a large part in the acceptability of code entry. AVA_MSU directs that any guidance be "reasonable"; however, reasonableness is somewhat subjective. The potential for insecure states must also be weighed in the decision; in particular, this potential will require additional procedures to verify that entered code corresponds to the code under configuration management (which was tested). There are many mechanisms and code entry approaches that could address this. Note that simple syntax checking is insufficient, as it does not verify that the semantics (which enforce security) are what the original programmer intended, only that the structure of the code meets the structural requirements of the language.

Modification History:

2006-04-05

PD created. (March 2006 ODRB Agenda Item 3.a.i)

2006-07-20

PD updated to provide a stronger basis for the decision, based on extensive discussion on cc-cmt, and input provided by the ODRB, Jim Arnold, Trey Henefield, Nir Naaman, Daniel Faigin, and others. (July 2006 ODRB Agenda Item 4.d.i)

References:

• None

Related NIs:

• I-0467: Can Guidance Documentation Meet TSF Requirements?

Related CCIMB-INTERPs:

• None

Source OD: 0248