home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / secpubs / doc-cert.txt < prev    next >
Text File  |  1995-09-15  |  33KB  |  854 lines

  1.  
  2.  
  3.  
  4.                      U. S. DEPARTMENT OF COMMERCE
  5.  
  6.                        ABBREVIATED CERTIFICATION
  7.                               METHODOLOGY
  8.                               GUIDELINES
  9.  
  10.                      FOR SENSITIVE AND CLASSIFIED 
  11.                         INFORMATION TECHNOLOGY 
  12.                                 SYSTEMS
  13.  
  14.  
  15.  
  16.  
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.                            December 1, 1992
  26.  
  27.  
  28.                      U. S. DEPARTMENT OF COMMERCE
  29.                  ABBREVIATED CERTIFICATION METHODOLOGY
  30.              FOR SENSITIVE INFORMATION TECHNOLOGY SYSTEMS
  31.  
  32.  
  33. A.    INTRODUCTION
  34.  
  35.       It is the policy of the Department of Commerce (DOC) to
  36.       comply fully with all federal statutes and directives on
  37.       information technology (IT) security and to provide
  38.       protection commensurate with the sensitivity of the systems
  39.       or data processed.  
  40.  
  41.       Protection requirements for each of the individual IT
  42.       systems within the Department will vary according to the
  43.       unique characteristics of the system, environmental
  44.       concerns, data sensitivity and mission related criticality
  45.       of the system or data.  Appropriate levels of security must
  46.       be determined by an evaluation of the threats,
  47.       vulnerabilities and risk factors associated with each
  48.       system.  Cost-effective controls that are adequate to
  49.       achieve an acceptable level of risk for the individual
  50.       system must then be implemented.
  51.  
  52.       The DOC "Information Technology Accreditation Policy" issued
  53.       on July 6, 1992 established the requirement for
  54.       accreditation of all unclassified sensitive and classified
  55.       national security IT systems.  Accreditation is the
  56.       authorization and approval, granted to a sensitive or
  57.       classified IT system to process, as an acceptable risk, in
  58.       an operational environment.  Accreditation is made on the
  59.       basis of recommendations from a technical certification
  60.       evaluation that the IT system meets all applicable federal
  61.       and DOC policies, regulations, and standards and that all
  62.       installed security safeguards appear to be adequate and
  63.       appropriate for the sensitivity of the system; that they are
  64.       operating correctly; or, that the system must be operated
  65.       under certain specified conditions or constraints.  
  66.  
  67.       The technical certification evaluation results are the basis
  68.       for the system owner's certification statement in the
  69.       accreditation request.
  70.  
  71. B.    PURPOSE
  72.  
  73.       The purpose of this document is to provide guidance on
  74.       appropriate procedures to follow in performing the technical
  75.       certification evaluations of all sensitive and classified
  76.       national security systems within the Department. 
  77.  
  78.       The DOC issued a "Methodology for Certifying Sensitive
  79.       Computer Applications" in March 1987.  The process described
  80.       in that document was required for any new DOC applications
  81.       or any modification of existing applications that handle
  82.       sensitive information.  It is especially suited for large
  83.       complicated applications, for applications which are in-
  84.       house developed or involve extensive modifications to
  85.       customize for Commerce use, applications with very high
  86.       sensitivity such as major financial applications which
  87.       process high dollar amounts or are subject to fraud or
  88.       abuse, or for new applications without existing security
  89.       documentation.  This original certification methodology
  90.       should be used for systems meeting the above criteria.  
  91.  
  92.       That methodology has proved to be far too complex for many
  93.       of the Department's systems.  The methodology described in
  94.       this document is an abbreviated form of this process,
  95.       developed to address existing sensitive systems with
  96.       extensive documentation already available.   It is intended
  97.       to handle smaller systems and applications such as those
  98.       associated with personal computers (PCs) or those systems
  99.       with only a few users, and turn-key or commercial systems
  100.       which were procured against a detailed set of security
  101.       specifications.  This abbreviated methodology stresses the
  102.       use of existing documentation wherever possible.  It can be
  103.       used for completing the technical certification evaluation
  104.       requirements for both application systems and general
  105.       support systems.  The term "system" used in this document is
  106.       intended to mean either of the following, as appropriate: 
  107.  
  108.       1.   Application Systems - Systems that perform clearly
  109.            defined functions for which there are readily
  110.            identifiable security considerations and needs.  Such a
  111.            system might actually comprise many individual
  112.            application programs and hardware, software, and
  113.            telecommunications components.  They can be either a
  114.            major software application or a combination of
  115.            hardware/software where the only purpose of the system
  116.            is to support a specific mission related function.  The
  117.            system may process multiple individual applications, if
  118.            all are related to a single mission function.
  119.  
  120.       2.   General Support Systems - These consist of hardware and
  121.            software that provide general automated data processing
  122.            or network support for a variety of users and
  123.            applications.  Individual applications may be less
  124.            easily distinguishable than in the previous category,
  125.            but such applications may contain sensitive
  126.            information, or be critical to the mission
  127.            accomplishment of the organization.  Even if none of
  128.            the individual applications are sensitive, the support
  129.            system itself may be considered sensitive if the
  130.            aggregate of applications and support provided are
  131.            critical to the mission of the operating unit.
  132.  
  133. C.    ABBREVIATED CERTIFICATION METHODOLOGY
  134.  
  135.       Certification is based on a technical evaluation of a
  136.       sensitive system to see how well it meets its security
  137.       requirements, including all applicable federal policies,
  138.       regulations, and standards.  The results of tests should
  139.       demonstrate that the installed security safeguards are
  140.       adequate and appropriate for the system.  The certification
  141.       process is the final step leading to accreditation of the
  142.       system.  Sensitive systems will be recertified and
  143.       reaccredited when substantial changes are made to the
  144.       system, when changes in requirements result in the need to
  145.       process data of a higher sensitivity, after the occurrence
  146.       of a serious security violation which raises questions about
  147.       the validity of an earlier certification, and in all cases
  148.       no less frequently than three years after a previous
  149.       certification.
  150.  
  151.       Certification evaluations are conducted by the organization
  152.       that owns the system.  The certification team should get
  153.       input from all who have involvement with the system,
  154.       including:
  155.  
  156.           IT security staff, 
  157.  
  158.           system owner staff, 
  159.  
  160.           computer program development staff, if the application
  161.            was developed in-house, and 
  162.  
  163.           the computer operations staff, if the application is
  164.            run on a computer managed by a separate organization.  
  165.  
  166.           users
  167.  
  168.       Representatives from as many of these organizations as
  169.       possible should be included on the Certification Review
  170.       Team.
  171.  
  172.       The certification methodology described in this document
  173.       consists of the following steps, which will be described
  174.       more fully in the rest of this document:
  175.  
  176.            Step 1.  Assemble a team
  177.            Step 2.  Collect existing documents
  178.            Step 3.  Describe the system and its sensitivity
  179.            Step 4.  Identify protection requirements and
  180.       vulnerabilities
  181.            Step 5.  Identify security features needed
  182.            Step 6.  Test the adequacy of controls
  183.            Step 7.  Evaluate test results
  184.            Step 8.  Certify the system
  185.  
  186.       Worksheet forms to document each step in the certification
  187.       process are provided in Appendix A.
  188.  
  189.  
  190.  
  191.  
  192.       Definitions
  193.  
  194.       Certification is a technical evaluation of a sensitive
  195.       system to see how well it meets necessary security
  196.       requirements, such as appropriate federal policies,
  197.       regulations, and standards.  
  198.  
  199.       The Certifying Official is a senior manager in the
  200.       organization which owns the system.  The system owner is the
  201.       organization which has functional responsibility for the
  202.       system.  The Certifying Official should be a manager who was
  203.       responsible for having the system developed or the
  204.       functional area that the system supports, who has a need for
  205.       the results produced by the system, and can allocate
  206.       resources to correct deficiencies in the security controls
  207.       for the system.
  208.  
  209.       The Certification Review Team will collect the information
  210.       needed for the certification process, identify
  211.       vulnerabilities, develop a list of needed security features,
  212.       develop tests of the adequacy of the features, and evaluate
  213.       the test results.
  214.  
  215.       Security features are controls that protect against the
  216.       identified vulnerabilities, such as fire and water alarms,
  217.       passwords and other access protection, use of removable
  218.       media for data storage, data validation controls, audit
  219.       trails, uninterruptable power sources to protect against
  220.       electrical outages, personnel screening, IT security
  221.       awareness training of users, etc.
  222.  
  223.       A sensitive system is one that requires some degree of
  224.       protection for confidentiality, integrity or availability. 
  225.       This includes data whose improper use or disclosure could
  226.       adversely affect the ability of an agency to accomplish its
  227.       mission, proprietary data, records about individuals
  228.       requiring protection under the privacy Act, and data not
  229.       releasable under the Freedom of Information Act.  If the
  230.       system is required for accomplishment of an agency mission
  231.       it need not contain any sensitive data.   
  232.  
  233.       Test scenarios are descriptions of the tests to be performed
  234.       to check the effectiveness of the security features
  235.       incorporated into the system.  They may include validation
  236.       of password constraints such as length and composition of
  237.       the password, entry of erroneous data to check data
  238.       validation controls, review of audit information produced by
  239.       the system, review of contingency plans and risk analyses,
  240.       etc.
  241.  
  242.       Vulnerabilities are ways in which the system may be attacked
  243.       or may fail.  They include susceptibility to physical
  244.       dangers such as fire or water, unauthorized access to
  245.       sensitive data, entry of erroneous data, denial of timely
  246.       service, fraud, etc.
  247.  
  248.       Methodology Approach
  249.  
  250.       Step 1 - Assemble a team:  The first step in the abbreviated
  251.       process is to assemble a team to gather the information and
  252.       documentation needed to assess and demonstrate the adequacy
  253.       of security measures used.  The team should include
  254.       representatives of IT security, application owners, software
  255.       development, computer systems, and users.  For very small
  256.       systems the users, software programming staff, and computer
  257.       systems staffs may be the same.  The IT security staff
  258.       provides an outside viewpoint to ensure that the best IT
  259.       security practices are used in protecting sensitive systems. 
  260.       Where computer system staff, software programmers, and users
  261.       are in separate organizations, it is important that all
  262.       points of view are represented in the process, to ensure
  263.       that user expectations of protection needs are addressed,
  264.       and that software and computer system constraints are
  265.       understood.
  266.  
  267.       Step 2 - Collect existing documents needed for the
  268.       certification evaluation:  These documents include, but are
  269.       not limited to:
  270.  
  271.            1.    system specifications and documentation
  272.            2.    system security plan
  273.            3.    risk analysis
  274.            4.    contingency and disaster recovery plans
  275.            5.    staff records on personnel and the IT Security
  276.                  Officer identification, training and position
  277.                  sensitivity levels 
  278.            6.    Internal Control Reviews, security reviews, etc.,
  279.       if existing
  280.  
  281.       Step 3 - Identify and describe the system to be certified
  282.       and describe why it is sensitive:  It is necessary to have a
  283.       written description of the purpose of the system, the
  284.       hardware and software environment on which the system is
  285.       operated, and a description of the sensitivity of the
  286.       system, including any special applicable laws and
  287.       regulations.  This information is readily available in the
  288.       Sensitive System Security Plan for the system being
  289.       certified.  If the certification is for a software
  290.       application system that will be used by others, the hardware
  291.       description should address the hardware needed to operate
  292.       the system, but the certification should focus on the
  293.       software application program.  Complete the blank sections
  294.       of Sensitive System Certification Worksheet 1, System
  295.       Description and attach a copy of the approved Sensitive
  296.       System Security Plan for the system being evaluated.  The
  297.       Worksheet identifies the section numbers in the security
  298.       plan where detailed information can be obtained for review.
  299.  
  300.       Step 4 - Identify protection requirements and
  301.       vulnerabilities:  Review the description of the protection
  302.       requirements for the system under the headings
  303.       confidentiality, integrity, and availability in Section
  304.       II.B. of the Sensitive System 
  305.       Security Plan.  Enter the levels of protection required
  306.       (high, medium, low) in the blanks provided on Worksheet 1.  
  307.  
  308.       Identify vulnerabilities for the system related to these
  309.       protection requirements.  Most vulnerabilities will be
  310.       addressed in the existing documents collected in Step 2. 
  311.       All sensitive systems should have a completed risk analysis. 
  312.       The risk analysis will identify vulnerabilities and their
  313.       consequences, such as unauthorized disclosure of
  314.       information, loss of data or other resources, denial of
  315.       service, decisions based on erroneous information, etc. 
  316.       System documentation is another source of information about
  317.       the vulnerabilities.  The security plan for the system being
  318.       evaluated contains information about specific
  319.       vulnerabilities and control measures addressed.  The team
  320.       should also review any existing Internal Control, Inspector
  321.       General (IG) or security review reports on the system, for
  322.       additional information on system vulnerabilities.  In
  323.       addition to the documentation, the team may need to
  324.       interview managers in the user organization to ascertain
  325.       their concerns about the sensitivity of the system and the
  326.       level of protection required.
  327.  
  328.       Complete the Sensitive System Certification Worksheet 2:
  329.       Identified Vulnerabilities by listing the identified
  330.       vulnerabilities.
  331.  
  332.       Step 5 - Identify security features needed:  The team next
  333.       needs to review existing documents to identify the controls
  334.       in place to address the vulnerabilities identified above. 
  335.       The risk analysis, security plans, and system documentation
  336.       reviewed for vulnerabilities also contain information on
  337.       controls used to reduce those vulnerabilities.  System
  338.       specifications, if they still exist, will also provide
  339.       information on the controls designed into the system.  The
  340.       team will also need to review the contingency and disaster
  341.       recovery plans for the system.  The team should interview
  342.       the IT System Security Officer to review installation IT
  343.       security procedures.  Staff training records will show the
  344.       level of IT security training given to application and
  345.       computer installation staff.  Staff records should also show
  346.       the sensitivity designation of staff positions and any
  347.       personnel investigations, required and conducted, for staff
  348.       in the affected positions.  Complete the Sensitive System
  349.       Certification Worksheet 3: Security Features.
  350.  
  351.       Step 6 - Test adequacy of controls:  Once vulnerabilities
  352.       and controls have been identified, the team should
  353.       selectively check the adequacy of the controls.  Some live
  354.       tests may be needed to ensure that documented controls
  355.       actually work.  Other controls may be reviewed through other
  356.       means.  Previous system reviews and system acceptance tests
  357.       may contain records of tests previously performed.  It is
  358.       not necessary to repeat these tests, if the system has not
  359.       changed since they were done.  The review of vulnerabilities
  360.       and controls should identify any areas not adequately
  361.       addressed.  Sensitive System Certification Worksheet 4:
  362.       Security Tests is used to list the tests to be performed. 
  363.       Use Sensitive System Certification Worksheet 5: Security
  364.       Test Results to record the results of the tests.  
  365.  
  366.       Step 7 - Evaluate the test results:  Once all tests are
  367.       completed, a summary of the evaluation of the tests should
  368.       be prepared. The team should then prepare recommendations
  369.       about certification.  Sensitive System Certification
  370.       Worksheet 6: Evaluation and Recommendations is used to
  371.       record the evaluation of test results and the team's
  372.       recommendation.  The recommendation section should be signed
  373.       by all members of the team and dated.  
  374.  
  375.           If the tests results indicate that all protection
  376.            requirements have been met, the team can recommend
  377.            certification with no further action required.
  378.  
  379.           The Certification Review Team may determine from the
  380.            test results that the protection requirements were not
  381.            met for the system.  In that case, the evaluation
  382.            discussion of test results should explain the
  383.            inadequacy of the controls in place.
  384.  
  385.           The team may alternatively certify that the basic
  386.            protection requirements have been met, but recommend
  387.            additional features be required.  This latter form of
  388.            certification is appropriate for certifying a software
  389.            application system which must have certain operating
  390.            system or hardware features in place for approved
  391.            operation.  This may also be used in recommending
  392.            interim accreditation pending installation of some
  393.            additional control not currently available.  
  394.  
  395.       Step 8 - Certification:  The official Certification document
  396.       is signed by a senior management official in the system
  397.       owning organization.  A sample certification document is
  398.       attached as Appendix B.
  399.  
  400.       There may be situations when the need for a system is such
  401.       that it must be put into operation before a full
  402.       certification is possible.  In this case, the Certifying
  403.       Official can provisionally certify the system for operation,
  404.       possibly with some restrictions, pending specific actions to
  405.       be completed in a predefined time frame.  This interim
  406.       certification cannot exceed one year.  These actions should
  407.       also be included as milestones in the security plan for the
  408.       system.  The certification process must be flexible enough
  409.       that it accommodates the need for operational efficiency as
  410.       well as adequate protection of the system.
  411.  
  412.                               APPENDIX A
  413.  
  414.                SENSITIVE SYSTEM CERTIFICATION WORKSHEETS
  415.  
  416. This Appendix contains a set of six worksheets to assist with
  417. documenting the certification evaluation of the system.  Each
  418. worksheet is preceded by a set of instructions and definitions
  419. which will provide guidance for completing the evaluation and the
  420. worksheet.
  421.  
  422.                 DIRECTIONS FOR COMPLETING WORKSHEET 1: 
  423.                           SYSTEM DESCRIPTION
  424.  
  425. Much of the information requested on Worksheet 1 is contained in
  426. the Security Plan for the system.  To avoid having to rewrite
  427. this information and have a ready reference to the needed
  428. information, attach a copy of the Security Plan behind Worksheet
  429. 1.  Each worksheet contains blank lines, where information must
  430. be entered.  This step is important to avoid confusion with other
  431. system certification evaluation documentation. 
  432.  
  433. System Name/Title is the name of the system used in the Security
  434. Plan for a sensitive system (Section I.B of the Security Plan). 
  435. To avoid confusion with other certification evaluation
  436. documentation this should be written on all worksheets.  
  437.  
  438. System ID is the unique six digit system identification number
  439. assigned for each sensitive system in the Department.  Again, to
  440. avoid confusion with other certification evaluation documentation
  441. this should be written on all worksheets.
  442.  
  443. System Owner is the name of the contact person in the owning
  444. organization who is knowledgeable about the system and protection
  445. requirements.  It may be the person listed as Information Contact
  446. (Section I.G) in the Security Plan.  Provide full address and
  447. phone number, including area code, for the owner.
  448.  
  449. Developer is the name of the person who is responsible for
  450. developing the software.  If this is a commercial application,
  451. put the name of the organization in this space.  If there is no
  452. developer or the developer's name is unknown, put "none" in this
  453. space.
  454.  
  455. General Description/Purpose is a description of the function and
  456. purpose of the system.  This information is contained in Section
  457. I.E of the Security Plan.
  458.  
  459. System Environment and Special Considerations is a description of
  460. the computer and software environment of the system.  This
  461. information is contained in Section I.F of the Security Plan.
  462.  
  463. Sensitivity of Information Handled describes why the system is
  464. sensitive.  
  465.  
  466.       Applicable Laws and Regulations lists any laws and
  467.       regulations that specifically apply to this system, such as
  468.       the Privacy Act.  This information is contained in Section
  469.       II.A of the Security Plan.
  470.  
  471.       General Description of Information Sensitivity is a
  472.       description of why the system is sensitive and the nature of
  473.       that sensitivity.  This information is contained in the
  474.       introduction to Section II.B of the Security Plan.
  475.  
  476. Description of Protection Requirements describes what makes the
  477. system sensitive.  The descriptions of protection needs for
  478. confidentiality, integrity, and availability are contained in
  479. Section II.B of the Security Plan.  Write in the designated level
  480. (high, medium, low) in the blanks provided.
  481.               SENSITIVE SYSTEM CERTIFICATION WORKSHEET 1
  482.                           SYSTEM DESCRIPTION System Name/Title System ID:
  483. System Owner
  484.  
  485. Address:   ______________________________________________________
  486.            _________
  487.            ______________________________________________________
  488.            _________
  489. Phone:     ______________________________________________________
  490.            _________ Programmer/Developer:
  491.  
  492. Address:   ______________________________________________________
  493.            _________
  494.            ______________________________________________________
  495.            _________
  496. Phone:     ______________________________________________________
  497.            _________ General Description/Purpose
  498.   (See Section I.E. of attached security plan.)
  499. System Environment and Special Consideration
  500.   (See Section I.F. of attached security plan).
  501.  
  502. Sensitivity of Information Handled:
  503.   Applicable Laws and Regulations Affecting the System
  504.   (See Section II.A. of attached security plan.)
  505.  
  506. General Description of Information Sensitivity
  507.   (See Section II.B. of attached security plan.)
  508. Description of Protection Requirements
  509.   See Section II.B. of attached security plan and fill in the
  510. designated level (high, medium, low) in the blanks.
  511.  
  512. Confidentiality ______
  513.  
  514. Integrity ______
  515.  
  516. Availability ______
  517.  
  518.  
  519.                 DIRECTIONS FOR COMPLETING WORKSHEET 2: 
  520.                       IDENTIFIED VULNERABILITIES
  521.  
  522.  
  523. System Name/Title and System ID are the same as on Worksheet 1.
  524.  
  525. Description of Identified Vulnerabilities should include the
  526. vulnerabilities that the system may have prior to putting
  527. controls in place.  These should have been identified in the risk
  528. analysis.  They might include physical vulnerabilities such as
  529. fire or disk crashes, entry of erroneous data, denial of service,
  530. and unauthorized access to information.
  531.               SENSITIVE SYSTEM CERTIFICATION WORKSHEET 2
  532.                       IDENTIFIED VULNERABILITIES System Name/Title System ID:
  533.  
  534. Description of Identified Vulnerabilities
  535.   (From Risk Analysis, Security Plan, system documentation,
  536. interviews and other review      reports - Risks that exist prior
  537.                                  to putting any controls in place)
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.                 DIRECTIONS FOR COMPLETING WORKSHEET 3: 
  568.                            SECURITY FEATURES
  569.  
  570.  
  571. System Name/Title and System ID are the same as on Worksheet 1.
  572.  
  573. Description of Security Features is a list of the security
  574. features used to protect this system.  They can be taken from
  575. Sections III.C of the Security Plan and include Management
  576. Controls, Development/Implementation Controls for application
  577. systems, Acquisition/Development/Installation Controls for
  578. general support systems, Operational Controls, Security Awareness
  579. and Training, Technical Controls and Complementary Controls
  580. Provided by General Support Systems for application systems or
  581. Controls Over the Security of Applications for general support
  582. systems.
  583.  
  584. Although, it is not necessary to include the level of detail
  585. contained in the Security Plan, the controls should be listed to
  586. provide a foundation for selecting tests to be performed to
  587. verify if the controls are adequate and appropriate and are
  588. operating as expected.
  589.               SENSITIVE SYSTEM CERTIFICATION WORKSHEET 3
  590.                            SECURITY FEATURES System Name/Title System ID:
  591. Description of Security Features:
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618.  
  619.  
  620.  
  621.  
  622.  
  623.  
  624.                 DIRECTIONS FOR COMPLETING WORKSHEET 4:
  625.                             SECURITY TESTS
  626.  
  627.  
  628. System Name/Title and System ID are the same as on Worksheet 1.
  629.  
  630. Test Scenarios should contain a numbered list of the tests to be
  631. preformed to verify the controls listed on Worksheet 3.  For more
  632. detail about the controls, see Section III.C. of the security
  633. plan.  
  634.  
  635.           If this is an existing system that has been in
  636.            operation for some time, the tests may selectively test
  637.            the most critical controls. 
  638.  
  639.           If the system is under, or just completed development,
  640.            or is a turn-key system, all security controls should
  641.            be tested.
  642.  
  643.           If testing has been done for a another recent review,
  644.            or during recent acceptance testing of the system, it
  645.            may not be necessary to repeat the tests.  It will be
  646.            necessary to review records of the prior tests, and
  647.            determine if the documentation of the tests and results
  648.            are adequate.   If it is determined that it is not
  649.            justified to repeat the tests, a statement should be
  650.            included on Worksheet 4 explaining the reason.  Also,
  651.            include enough information about all supporting
  652.            documentation reviewed, to allow it to be located for
  653.            future reference.  At a minimum, include a list of
  654.            tests from the documentation, that were performed. 
  655.            This list need not contain as much detail for each
  656.            individual test as the referenced documentation. 
  657.  
  658.               SENSITIVE SYSTEM CERTIFICATION WORKSHEET 4
  659.                             SECURITY TESTS System Name/Title System ID:
  660. Test Scenario:
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.  
  683.  
  684.  
  685.  
  686.  
  687.  
  688.  
  689.  
  690.  
  691.  
  692.  
  693.                 DIRECTIONS FOR COMPLETING WORKSHEET 5:
  694.                          SECURITY TEST RESULTS
  695.  
  696.  
  697. System Name/Title and System ID are the same as on Worksheet 1.
  698.  
  699. Test Results reports the results of each of the tests described
  700. on Worksheet 4.  The numbers on Worksheet 5 for each test result
  701. should agree with the numbers on Worksheet 4 for the test
  702. description.  Indicate whether the was "Passed" or "Failed".
  703.  
  704.  
  705.               SENSITIVE SYSTEM CERTIFICATION WORKSHEET 5
  706.                          SECURITY TEST RESULTS System Name/Title System ID:
  707. Test Results:
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730.  
  731.  
  732.  
  733.  
  734.  
  735.  
  736.  
  737.  
  738.  
  739.  
  740.                 DIRECTIONS FOR COMPLETING WORKSHEET 6:
  741.                     EVALUATION AND RECOMMENDATIONS
  742.  
  743.  
  744. System Name/Title and System ID are the same as on Worksheet 1.
  745.  
  746. Evaluation of Test Results should discuss the results of the
  747. tests and their relationship to assuring the adequacy of
  748. controls.
  749.  
  750. Under Recommendations check one of the three responses.  
  751.  
  752.           Check Tests indicate that protection requirements were
  753.            met if all tests resulted in correct results.
  754.  
  755.           Check Tests indicate that protection requirements were
  756.            not met if some tests failed and corrections have not
  757.            been, or cannot be implemented.
  758.  
  759.           Check Tests indicate that protection requirements were
  760.            met; recommend certification with the following
  761.            additional security features required: if there are
  762.            additional security controls needed to meet the
  763.            protection requirements.  This category should be used
  764.            when certifying software applications that require
  765.            hardware or operating system features to assure
  766.            adequate protection.  It should also be used if an
  767.            interim certification is being recommended, pending
  768.            completion of specific actions.
  769.  
  770. Certifying Team Signatures should included printed names of the
  771. certifying team members, a signature, and a date for each team
  772. member.
  773.  
  774.               SENSITIVE SYSTEM CERTIFICATION WORKSHEET 6
  775.                     EVALUATION AND RECOMMENDATIONS System Name/Title System
  776. ID:
  777. Evaluation of Test Results:
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785. Recommendations:
  786.  
  787.       _____      Tests indicate that protection requirements were
  788.                  met.
  789.            RECOMMEND CERTIFICATION OF THIS SYSTEM.
  790.  
  791.       _____      Tests indicate that protection requirements were
  792.                  not met.  RECOMMEND THAT THIS SYSTEM NOT BE
  793.                  CERTIFIED.
  794.  
  795.       _____      Tests indicate that protection requirements were
  796.                  met; recommend certification with the following
  797.                  additional security features required:
  798.  
  799.  
  800.  
  801.  
  802. Certifying Team Signatures
  803.  
  804.  
  805.      Name                        Signature                      
  806.        Date
  807.  
  808. _______________________________________________________________
  809. ____________
  810.  
  811. _______________________________________________________________
  812. ____________
  813.  
  814. _______________________________________________________________
  815. ____________ 
  816.  
  817.  
  818.  
  819.                               Appendix B
  820.  
  821.                     Sample Certification Statement
  822.  
  823.  
  824. I have carefully examined the certification worksheets for DOC
  825. Information Technology System Number _________, "Insert system
  826. name/title", dated ___________________ .  Based on the
  827. information contained in this package and the results of tests
  828. conducted on the system, it is my judgment that satisfactory
  829. information technology controls are in place to adequately
  830. protect the system and that it is operating at an acceptable
  831. level of risk.  
  832.  
  833. I hereby certify DOC IT System Number ________, "Insert system
  834. name/title", for a period not to exceed three years.  Should
  835. substantial changes or security incidents occur during that three
  836. year period, which bring the adequacy of the protection measures
  837. for this system into question, a reevaluation and recertification
  838. must be completed earlier.
  839.  
  840.  
  841.  
  842.  
  843. Certification Official Name/Title: 
  844.  
  845.       ______________________________________________                   
  846.                  
  847.       ______________________________________________
  848.  
  849.  
  850. Signature: _____________________________________________  Date:
  851. ____________
  852.  
  853.  
  854.