DI-NDTI-81351
Security Test Plan
The Security Test Plan outlines the test plans and security objectives for a set of specific security tests, providing the concept, objectives, support needs, and analysis techniques used to test the security mechanisms of the trusted computing base.
Approval DateJuly 2, 1993
AMSC NumberG6941
Preparing Activity—
Project Number—
OPRG/C71
DTIC Applicable—
GIDEP Applicable—
Limitation—
Applicable Forms—
Approval Limitation—
Form VersionAPR 89
DID Formatdd_form_1664
963C CompliantNo
DISTRIBUTION STATEMENT A: Approved for public release; distribution is unlimited.
Supersedes
—Related
—Description & Purpose
The Security Test Plan outlines the test plans and security objectives for a set of specific security tests to be performed. It provides the test concept, reasons, objectives and requirements to be satisfied, support needed, responsible activities associated with the testing, and analysis techniques to be used. It shall provide the strategy to test the security mechanisms of the trusted computing base (TCB).
Application & Interrelationship
7.1 This Data Item Description (DID) contains the format and content preparation instructions for the data product generated under the work task described by 2.2.3.2.1, 3.1.3.2.1, 3.2.3.2.1, 3.3.3.2.1 and 4.1.3.2.1 of DOD-5200.28 STD, Department of Defense Trusted Computer System Evaluation Criteria.
7.2 This DID is applicable to any computer acquisition that requires test documentation for the security features as specified by DOD-5200.28 STD, Department of Defense Trusted Computer System Evaluation Criteria (TCSEC), Classes C1 (Discretionary Security Protection), and above, products or their equivalent systems.
7.3 The Security Test Plan is generally produced to support certification and accreditation.
7.4 The information required by 10.3 is required for all class products and their equivalent systems applicable to the DID as a whole. In addition, the information required in 10.3.1, 10.3.2, 10.3.3, 10.3.4, 10.3.5, 10.3.6 and 10.3.7 is necessary for various classes of products and their equivalent systems.
Use & Relationship
—
Preparation Instructions
10.1Source Document.The applicable issue of the documents cited herein, including their approval date, and dates of any applicable amendments and revisions shall be reflected in the contract
10.2Format.Document a Security Test Plan as follows:
10.2.1Cover Sheet.Shall contain Title, Contract Number, Procuring Activity, Contractor Identification, Acquisition Program Name, disclaimers (as provided by the procuring activity contracting officer), date, version number, security classification, and any other appropriate descriptive data.
10.2.2Errata Sheet.Shall contain sheets delimiting cumulative page changes from previous version(s).
10.2.3Table of Contents.Shall contain paragraph numbers, paragraph names, and page numbers.
10.2.4List of illustrations, diagrams, charts and figures.
10.2.5Glossary of abbreviations, acronyms, terms, symbols, and notation used, and their definitions.
10.2.6Executive Summary, not to exceed two pages, that briefly summarizes the Security Test Plan.
10.2.7Introduction.
10.2.8Body of the Plan.
10.2.9Attachments.
10.2.10Appendices.
10.2.11Bibliography.List references and all applicable documents.
10.2.12Subjective index.
10.2.13Specific format instructions.
10.2.13.1Abbreviations and acronyms shall be defined when first used in the text and shall be placed in the glossary.
10.2.13.2Pages shall be numbered separately and consecutively using Arabic numerals.Blank pages shall be numbered.
10.2.13.3Paragraphs shall have a short descriptive title and shall be numbered consecutively using Arabic Numerals.Numbering schemes beyond the fourth level (e.g., 4.1.2.5.8) are not permitted.
10.2.13.4Chapters shall begin on an odd-numbered (right-handed) page.
10.2.13.5Column headings shall be repeated on subsequent pages if tabular material exceeds one page.
10.2.13.6Fold out pages shall be kept to a minimum.
10.2.13.7Paper shall be standard 8 1/2 x 11 inches, white, with black type.Use standard 10 inch pica or courier, 12 pitch elite, or equivalent font. Either blocked text (left and right justified) or jagged right (left justified only) shall be used.
10.2.13.8At least one inch margins shall be provided all around each page to allow for drilling and binding.
10.2.13.9Either single- or double-sided printing shall be used.If double-sided, the document shall be printed or typed head-to-head, front-to-back.
10.2.13.10The plan shall be provided in standard three ring notebook binders for ease of maintenance.
10.3Content.The Security Test Plan shall include the method by which testing will be performed to determine whether the TCB works as claimed in the documentation. It shall describe how testing will be done to assure that there are no obvious ways for an unauthorized user to bypass or otherwise defeat the security protection mechanisms of the TCB. The Security Test Plan shall include the following:
10.3.1An overview of the TCB that will be tested.It shall briefly describe the security protection mechanism(s).
10.3.2A description of the objectives of the test plan, including the following:
10.3.2.1A functional description of the security test program.
10.3.2.2Government and contractor participation roles and responsibilities.
10.3.2.3Facilities where the testing will be performed.
10.3.2.4Support requirements for the tests (e.g., communications, equipment, test data, etc).
10.3.2.5Schedule of when testing will be performed.
10.3.3A list of all tests to be accomplished in the order they are to be performed.The list shall include a test for each security protection function (e.g., unauthorized access to audit data). Each listing shall include the following:
10.3.3.1Name and brief description of test to be performed.
10.3.3.2Reason for performing test.
10.3.3.3Functional requirements which will be tested.
10.3.3.4Objective to be satisfied by each test, including the pass/fail criteria, baseline, duration, and number of times each test should be performed.
10.3.3.5Specific test support requirements for each test performed.
10.3.3.6Start and expected completion dates of each test to be performed.
10.3.4Description of the data reduction and analysis techniques that will be used to interpret the data.
10.3.5An overview of the procedures that will be used to validate the test results.
10.3.6Class C2 products and their equivalent systems.The Security Test Plan shall include a plan for the search for obvious flaws that would:
10.3.6.1Allow violation of resource isolation.
10.3.6.2Permit unauthorized access to the audit or authentication data.
10.3.7Class B1 products and their equivalent systems.The Security Test Plan shall describe the test program's approach to identify and report flaws so that the flaws may be removed or neutralized. It shall include the approach to retest identified flaws to demonstrate that they have been eliminated. This approach shall include regression testing to ascertain whether new flaws have been introduced when removing the originally discovered flaw.
10.3.8Class B1 and above products and their equivalent systems.The following shall be included:
10.3.8.1A description of how the design documentation, source code, and object code will be thoroughly analyzed and tested.
10.3.8.2The plan for tests to:
10.3.8.2.1Uncover all design and implementation flaws that would permit a subject external to the TCB to read, change, or delete data normally denied under the mandatory or discretionary security policy enforced by the TCB.
10.3.8.2.2Assure that no subject (without authorization to do so) is able to cause the TCB to enter a state such that it is unable to respond to communications initiated by other users.
10.3.9Class B2 products and their equivalent systems.The following shall be included: regression testing to ascertain whether new flaws have been introduced when removing the originally discovered flaw.
10.3.9.1A description of the technique to demonstrate that the TCB is relatively resistant to penetration.
10.3.9.2A description of the test program's approach to retest identified flaws to demonstrate that they have been corrected.This approach shall include the originally discovered flaw.
10.3.10Class B2 and B3 products and their equivalent systems.The Security Test Plan shall describe the technique to demonstrate that the TCB implementation is consistent with the Descriptive Top Level Specification.
10.3.11Class B3 and above products and their equivalent systems.The following shall be included:
10.3.11.1A description of the technique that will be used to determine that the TCB is resistant to penetration.
10.3.11.2A description of the approach that will be used to prevent design flaws and limit implementation flaws from being found during the final security testing.This approach shall provide a reasonable confidence that few flaws remain for security testing.
10.3.11.3The Security Test Plan shall include the following test planning for trusted recovery:
10.3.11.3.1Test conditions; i.e., a list of discontinuities of operation that can be generated through administrative interfaces and their effects.
10.3.11.3.2Test data, consisting of the following:
10.3.11.3.2.1Environment setup; e.g., the TCB and user-level data structures and objects needed to generate the planned discontinuity.
10.3.11.3.2.2Parameters and commands used by the administrators to generate the discontinuity.
10.3.11.3.2.3Expected outcome; e.g., the type of procedures that are started automatically or manually for handling the generated discontinuity and the effect of those procedures on the TCB state.
10.3.11.3.3Coverage analysis; e.g., this includes a list of failures, or classes of failures, whose effect is covered by the generated discontinuities, and a list of spontaneous failures, or classes of failures, whose effect isn't covered by the test.
10.3.12Class A1 products and their equivalent systems.The following shall be included:
10.3.12.1A description of the technique to demonstrate that the TCB implementation is consistent with the Formal Top Level Specification (FTLS).
10.3.12.2A description of how the mapping of the FTLS to the source code may form a basis for penetration testing.
References
—
Schema v3.0Community-maintained · Verify against ASSIST
Community-maintained — not an official government database.
Verify against ASSIST·GitHub·About·Disclaimer
Verify against ASSIST·GitHub·About·Disclaimer