Previous Table of Contents Next


They can be applied to individual controls or to entire applications. Testing is the best way to evaluate performance and the specific tests needed for each of these factors. A useful technique here is stress testing. This can involve using large numbers of users and requests, large amounts of background activity, or maximum resources to attain conditions of operational stress. Functional operation might also be examined under these conditions because stress loading often interferes with regular processing. Stress testing is also used to attempt to exhaust quota limits for such specific resources as buffers, queues, tables, and ports. These resources might be external or internal to the application and might support such application functions as jobs, transactions, and sessions. This directed stress testing is especially useful in evaluating protection against denial-of-service threats.

Review Penetration Resistance. The final area of concern in detailed evaluation is penetration resistance. The task here is to assess resistance against the breaking or circumventing of controls. Cryptanalysis is an example of a technique for breaking a particular control—encryption. Creating and using a fraudulent logon utility to discover passwords is an example of control circumvention. The nature of the evaluation activity here differs widely, depending on whether the potential penetrators are users, operators, application programmers, system programmers, managers, or external personnel. In addition, the notion of penetration resistance applies not only to attacks against data but to physical assets and performance.

Assessment of penetration resistance can be the most technically complex of the detailed evaluation categories. It is best performed to establish confidence in security safeguards and to find and correct flaws. In both cases, it:

  Provides an assessment of an application’s penetration resistance
  Helps determine the difficulties involved in actually exploiting flaws
  Provides a clear demonstration of flaw exploitability (e.g., it might not be clear from analysis whether an asynchronous timing flaw can be exploited)

PREPARE REPORT OF RESULTS

The security evaluation report is the primary product of certification. It contains technical security recommendations for the application and is the main basis for the decision on the adequacy of security. The evaluation work is partitioned into three areas:

  Application software and administrative and procedural safeguards
  Physical security
  Operating systems and hardware

Most of the internal work is in the area of application software and administrative and procedural safeguards. The results of detailed evaluations are combined with basic evaluation results; all of the results are then integrated into the security testing report. It is preferable to integrate results from different evaluation areas into one final report rather than deliver several reports to management; the safeguards in each area can have complex interrelationships that require a technical interpretation.

Report Preparation. The report is composed of these sections:

  Introduction and Summary. This section briefly describes the application and summarizes testing results and recommendations.
  Background. This section provides contextual information. One important item is the security standards or policies that were applied. Another is a list of the general functional characteristics of the application (e.g., the presence or absence of user programming). Application boundaries are defined, along with security assumptions about areas outside the boundaries.
  Major Results. The first portion of this section summarizes the controls that are in place and their general roles in protecting assets against threats and preventing exposures. This emphasizes those areas in which safeguards are acceptable. The second portion summarizes major vulnerabilities. Vulnerabilities are divided into two categories: proposed residual vulnerabilities and proposed vulnerabilities requiring correction. This format serves as both a summary of results and a recommendation of which vulnerabilities to accept and which to correct. Authority to approve the recommendations resides with management.

Recommended Corrective Actions. Corrective actions and their anticipated costs are recommended and ranked. Responsibility for making the corrections might be proposed. Criteria for evaluating the corrections must be established. This section must be sufficiently complete to give a clear understanding of the implications of either accepting or correcting vulnerabilities. Because sensitive applications are usually also important to the company’s operations, most flaws are not severe enough to remove an operational application from service, although some restrictions may need to be implemented immediately. Other than removing an application from service or delaying its implementation, there are many intermediate options available, including:

  Adding procedural security controls and restricting use of the application to sites that have compensating controls
  Restricting the application to process only nonsensitive or minimally sensitive data
  Removing especially vulnerable application functions or components (e.g., in a network environment, a particularly weak node might be excluded)
  Restricting use of the application to noncritical situations in which errors or failures are less severe
  Removing dial-up access (relying more on physical security)

Certification Process. This section summarizes the work performed in the certification process to enable management to determine the confidence that can be placed in the findings. The section should have the following appended:

  Attachment A, Proposed Accreditation Statement. This is a critical part of the report; it summarizes recommended actions. Judgments and recommendations embodied in the statement are subject to approval by management.
  Attachment B, Detailed Evaluation Reports. These describe the full set of findings, not just major ones. It can be useful, especially if separate evaluation teams are participating, to use standard forms to present basic and detailed findings.


Previous Table of Contents Next