Previous Table of Contents Next


Control Existence Determination. Because controls are described in a document or discussed in an interview does not prove that they have been implemented. Basic evaluations must ensure that security controls exist. The existence of most physical and administrative controls can be determined through inspection. For controls internal to the computer, testing is needed. Such testing does not gather significant evidence toward determining how well controls work (that is beyond the scope of a basic evaluation). The intent is simply to verify that the functions exist. On the other hand, quality must be kept in mind in case there are fundamental shortcomings that call into question the overall effectiveness of the functions. A particularly vulnerable area here is the susceptibility of procedural controls to human error.

Tests for control existence determination are straightforward. In many cases, a short operational demonstration suffices. For example, the existence of a password function can be determined by attempting to use the application and verifying that a valid password is required. The existence of an access function can be determined by verifying that access is not allowed unless explicitly granted (e.g., by the file owner). External testing is generally sufficient for control existence determination.

Methodology Review. Control existence determination verifies that controls exist; it says nothing about their quality. Although this is a high-level evaluation, it is still desirable to gain some assurance that controls are acceptably implemented. The best way to do this without becoming immersed in testing or detailed analysis is to examine the methodology used to develop the application. A methodology review can help determine the extent to which controls are reliably implemented and the susceptibility of the application to flaws. If review findings suggest that the implementation cannot be relied on, detailed evaluation is typically required to find specific flaws.

CONDUCT DETAILED EVALUATION

In many cases, a basic evaluation does not provide sufficient evidence for certification. Examples are cases in which the basic evaluation reveals problems that require further analysis, the application has a high degree of sensitivity, or primary security safeguards are embedded in detailed internal functions that are not able to be examined at the basic evaluation level. These situations require detailed evaluations to obtain additional evidence and increased confidence in evaluation judgments. Detailed evaluations involve analysis of the quality of security safeguards. Primary subtasks are examinations of the application in three areas:

  Review functional operation. Do controls function properly?
  Review performance. Do controls satisfy performance criteria?
  Review penetration resistance. How readily can controls be broken or circumvented?

It is rarely feasible or desirable, even in a detailed evaluation, to examine everything. Two strategies are presented for focusing on small portions of security. One is based on security-relevant components and the other on situational analysis.

Security Components. This strategy is based on four components relevant to IT security: assets, exposures, threats, and controls. All of the components have already been considered in the basic evaluation or in a risk analysis. The current activity involves a detailed view. It can use basic evaluation or risk analysis data when suitable and extensions of such data, as needed, for the analysis reports. The list of sample analysis reports discussed for each component can be expanded. It illustrates that a variety of reports may be needed. The questions of how many and which types depend on evaluation results.

Assets. Assets are the tangible and intangible resources of an organization. The evaluation issue here is to determine what should be protected. It might be useful to examine assets (e.g., data, files, physical resources) in detail, along with their relevant attributes (e.g., amount, value, use, and characteristics). A variety of specific tasks may be needed. For example, an asset value analysis determines how the value differs among users and potential attackers; an asset exploitation analysis examines different ways to use an asset for illicit gain.

Threats. Threats are possible events with the potential to cause loss or harm. It is important to distinguish among accidental, intentional, and natural threats. Intentional threats can be the most complex. An example of an analysis task for intentional threats is to identify perpetrator classes (e.g., programmers, operators, and users) on the basis of knowledge, skills, and access privileges. Another useful analysis examines the factors affecting threat frequency. Threat frequency depends on such factors as threat magnitudes, assets (and whether their loss is full or partial), relevant exposures, existing controls, and expected gain on the part of the perpetrator. The nature of the threats can influence evaluation methods used. For example, a standard evaluation technique is to review samples of source code to determine compliance with established programming practices and to look for security flaws. If the threat is a malicious programmer, however, the assembled object code rather than the source code or specifications is reviewed.

Exposures. Exposures are areas of susceptibility to loss or harm. The evaluation issue is to determine what might happen to assets if a threat (internal failure, human error, attack, or natural disaster) is realized. Examples of exposures are disclosure violations, erroneous decisions, and fraud. An example of an exposure analysis is the examination of the impact (e.g., greatly increased response time for a service) of a particular exposure. Much exposure analysis focuses on identifying areas in which exposures are the greatest. The question of which exposure types represent the areas of greatest loss or harm can have a major influence on detailed evaluation activities. For example, if integrity or accuracy is the primary concern, the evaluation focuses on the basic application processing; if disclosure is the primary concern, the evaluation focuses on those functions and interfaces associated with disclosure protection.


Previous Table of Contents Next