TUCoPS :: General Information :: cert_m_1.txt


                     U. S. DEPARTMENT OF COMMERCE

                       ABBREVIATED CERTIFICATION

                     FOR SENSITIVE AND CLASSIFIED 
                        INFORMATION TECHNOLOGY 

                           December 1, 1992

                     U. S. DEPARTMENT OF COMMERCE


      It is the policy of the Department of Commerce (DOC) to
      comply fully with all federal statutes and directives on
      information technology (IT) security and to provide
      protection commensurate with the sensitivity of the systems
      or data processed.  

      Protection requirements for each of the individual IT
      systems within the Department will vary according to the
      unique characteristics of the system, environmental
      concerns, data sensitivity and mission related criticality
      of the system or data.  Appropriate levels of security must
      be determined by an evaluation of the threats,
      vulnerabilities and risk factors associated with each
      system.  Cost-effective controls that are adequate to
      achieve an acceptable level of risk for the individual
      system must then be implemented.

      The DOC "Information Technology Accreditation Policy" issued
      on July 6, 1992 established the requirement for
      accreditation of all unclassified sensitive and classified
      national security IT systems.  Accreditation is the
      authorization and approval, granted to a sensitive or
      classified IT system to process, as an acceptable risk, in
      an operational environment.  Accreditation is made on the
      basis of recommendations from a technical certification
      evaluation that the IT system meets all applicable federal
      and DOC policies, regulations, and standards and that all
      installed security safeguards appear to be adequate and
      appropriate for the sensitivity of the system; that they are
      operating correctly; or, that the system must be operated
      under certain specified conditions or constraints.  

      The technical certification evaluation results are the basis
      for the system owner's certification statement in the
      accreditation request.


      The purpose of this document is to provide guidance on
      appropriate procedures to follow in performing the technical
      certification evaluations of all sensitive and classified
      national security systems within the Department. 

      The DOC issued a "Methodology for Certifying Sensitive
      Computer Applications" in March 1987.  The process described
      in that document was required for any new DOC applications
      or any modification of existing applications that handle
      sensitive information.  It is especially suited for large
      complicated applications, for applications which are in-
      house developed or involve extensive modifications to
      customize for Commerce use, applications with very high
      sensitivity such as major financial applications which
      process high dollar amounts or are subject to fraud or
      abuse, or for new applications without existing security
      documentation.  This original certification methodology
      should be used for systems meeting the above criteria.  

      That methodology has proved to be far too complex for many
      of the Department's systems.  The methodology described in
      this document is an abbreviated form of this process,
      developed to address existing sensitive systems with
      extensive documentation already available.   It is intended
      to handle smaller systems and applications such as those
      associated with personal computers (PCs) or those systems
      with only a few users, and turn-key or commercial systems
      which were procured against a detailed set of security
      specifications.  This abbreviated methodology stresses the
      use of existing documentation wherever possible.  It can be
      used for completing the technical certification evaluation
      requirements for both application systems and general
      support systems.  The term "system" used in this document is
      intended to mean either of the following, as appropriate: 

      1.   Application Systems - Systems that perform clearly
           defined functions for which there are readily
           identifiable security considerations and needs.  Such a
           system might actually comprise many individual
           application programs and hardware, software, and
           telecommunications components.  They can be either a
           major software application or a combination of
           hardware/software where the only purpose of the system
           is to support a specific mission related function.  The
           system may process multiple individual applications, if
           all are related to a single mission function.

      2.   General Support Systems - These consist of hardware and
           software that provide general automated data processing
           or network support for a variety of users and
           applications.  Individual applications may be less
           easily distinguishable than in the previous category,
           but such applications may contain sensitive
           information, or be critical to the mission
           accomplishment of the organization.  Even if none of
           the individual applications are sensitive, the support
           system itself may be considered sensitive if the
           aggregate of applications and support provided are
           critical to the mission of the operating unit.


      Certification is based on a technical evaluation of a
      sensitive system to see how well it meets its security
      requirements, including all applicable federal policies,
      regulations, and standards.  The results of tests should
      demonstrate that the installed security safeguards are
      adequate and appropriate for the system.  The certification
      process is the final step leading to accreditation of the
      system.  Sensitive systems will be recertified and
      reaccredited when substantial changes are made to the
      system, when changes in requirements result in the need to
      process data of a higher sensitivity, after the occurrence
      of a serious security violation which raises questions about
      the validity of an earlier certification, and in all cases
      no less frequently than three years after a previous

      Certification evaluations are conducted by the organization
      that owns the system.  The certification team should get
      input from all who have involvement with the system,

          IT security staff, 

          system owner staff, 

          computer program development staff, if the application
           was developed in-house, and 

          the computer operations staff, if the application is
           run on a computer managed by a separate organization.  


      Representatives from as many of these organizations as
      possible should be included on the Certification Review

      The certification methodology described in this document
      consists of the following steps, which will be described
      more fully in the rest of this document:

           Step 1.  Assemble a team
           Step 2.  Collect existing documents
           Step 3.  Describe the system and its sensitivity
           Step 4.  Identify protection requirements and
           Step 5.  Identify security features needed
           Step 6.  Test the adequacy of controls
           Step 7.  Evaluate test results
           Step 8.  Certify the system

      Worksheet forms to document each step in the certification
      process are provided in Appendix A.


      Certification is a technical evaluation of a sensitive
      system to see how well it meets necessary security
      requirements, such as appropriate federal policies,
      regulations, and standards.  

      The Certifying Official is a senior manager in the
      organization which owns the system.  The system owner is the
      organization which has functional responsibility for the
      system.  The Certifying Official should be a manager who was
      responsible for having the system developed or the
      functional area that the system supports, who has a need for
      the results produced by the system, and can allocate
      resources to correct deficiencies in the security controls
      for the system.

      The Certification Review Team will collect the information
      needed for the certification process, identify
      vulnerabilities, develop a list of needed security features,
      develop tests of the adequacy of the features, and evaluate
      the test results.

      Security features are controls that protect against the
      identified vulnerabilities, such as fire and water alarms,
      passwords and other access protection, use of removable
      media for data storage, data validation controls, audit
      trails, uninterruptable power sources to protect against
      electrical outages, personnel screening, IT security
      awareness training of users, etc.

      A sensitive system is one that requires some degree of
      protection for confidentiality, integrity or availability. 
      This includes data whose improper use or disclosure could
      adversely affect the ability of an agency to accomplish its
      mission, proprietary data, records about individuals
      requiring protection under the privacy Act, and data not
      releasable under the Freedom of Information Act.  If the
      system is required for accomplishment of an agency mission
      it need not contain any sensitive data.   

      Test scenarios are descriptions of the tests to be performed
      to check the effectiveness of the security features
      incorporated into the system.  They may include validation
      of password constraints such as length and composition of
      the password, entry of erroneous data to check data
      validation controls, review of audit information produced by
      the system, review of contingency plans and risk analyses,

      Vulnerabilities are ways in which the system may be attacked
      or may fail.  They include susceptibility to physical
      dangers such as fire or water, unauthorized access to
      sensitive data, entry of erroneous data, denial of timely
      service, fraud, etc.

      Methodology Approach

      Step 1 - Assemble a team:  The first step in the abbreviated
      process is to assemble a team to gather the information and
      documentation needed to assess and demonstrate the adequacy
      of security measures used.  The team should include
      representatives of IT security, application owners, software
      development, computer systems, and users.  For very small
      systems the users, software programming staff, and computer
      systems staffs may be the same.  The IT security staff
      provides an outside viewpoint to ensure that the best IT
      security practices are used in protecting sensitive systems. 
      Where computer system staff, software programmers, and users
      are in separate organizations, it is important that all
      points of view are represented in the process, to ensure
      that user expectations of protection needs are addressed,
      and that software and computer system constraints are

      Step 2 - Collect existing documents needed for the
      certification evaluation:  These documents include, but are
      not limited to:

           1.    system specifications and documentation
           2.    system security plan
           3.    risk analysis
           4.    contingency and disaster recovery plans
           5.    staff records on personnel and the IT Security
                 Officer identification, training and position
                 sensitivity levels 
           6.    Internal Control Reviews, security reviews, etc.,
      if existing

      Step 3 - Identify and describe the system to be certified
      and describe why it is sensitive:  It is necessary to have a
      written description of the purpose of the system, the
      hardware and software environment on which the system is
      operated, and a description of the sensitivity of the
      system, including any special applicable laws and
      regulations.  This information is readily available in the
      Sensitive System Security Plan for the system being
      certified.  If the certification is for a software
      application system that will be used by others, the hardware
      description should address the hardware needed to operate
      the system, but the certification should focus on the
      software application program.  Complete the blank sections
      of Sensitive System Certification Worksheet 1, System
      Description and attach a copy of the approved Sensitive
      System Security Plan for the system being evaluated.  The
      Worksheet identifies the section numbers in the security
      plan where detailed information can be obtained for review.

      Step 4 - Identify protection requirements and
      vulnerabilities:  Review the description of the protection
      requirements for the system under the headings
      confidentiality, integrity, and availability in Section
      II.B. of the Sensitive System 
      Security Plan.  Enter the levels of protection required
      (high, medium, low) in the blanks provided on Worksheet 1.  

      Identify vulnerabilities for the system related to these
      protection requirements.  Most vulnerabilities will be
      addressed in the existing documents collected in Step 2. 
      All sensitive systems should have a completed risk analysis. 
      The risk analysis will identify vulnerabilities and their
      consequences, such as unauthorized disclosure of
      information, loss of data or other resources, denial of
      service, decisions based on erroneous information, etc. 
      System documentation is another source of information about
      the vulnerabilities.  The security plan for the system being
      evaluated contains information about specific
      vulnerabilities and control measures addressed.  The team
      should also review any existing Internal Control, Inspector
      General (IG) or security review reports on the system, for
      additional information on system vulnerabilities.  In
      addition to the documentation, the team may need to
      interview managers in the user organization to ascertain
      their concerns about the sensitivity of the system and the
      level of protection required.

      Complete the Sensitive System Certification Worksheet 2:
      Identified Vulnerabilities by listing the identified

      Step 5 - Identify security features needed:  The team next
      needs to review existing documents to identify the controls
      in place to address the vulnerabilities identified above. 
      The risk analysis, security plans, and system documentation
      reviewed for vulnerabilities also contain information on
      controls used to reduce those vulnerabilities.  System
      specifications, if they still exist, will also provide
      information on the controls designed into the system.  The
      team will also need to review the contingency and disaster
      recovery plans for the system.  The team should interview
      the IT System Security Officer to review installation IT
      security procedures.  Staff training records will show the
      level of IT security training given to application and
      computer installation staff.  Staff records should also show
      the sensitivity designation of staff positions and any
      personnel investigations, required and conducted, for staff
      in the affected positions.  Complete the Sensitive System
      Certification Worksheet 3: Security Features.

      Step 6 - Test adequacy of controls:  Once vulnerabilities
      and controls have been identified, the team should
      selectively check the adequacy of the controls.  Some live
      tests may be needed to ensure that documented controls
      actually work.  Other controls may be reviewed through other
      means.  Previous system reviews and system acceptance tests
      may contain records of tests previously performed.  It is
      not necessary to repeat these tests, if the system has not
      changed since they were done.  The review of vulnerabilities
      and controls should identify any areas not adequately
      addressed.  Sensitive System Certification Worksheet 4:
      Security Tests is used to list the tests to be performed. 
      Use Sensitive System Certification Worksheet 5: Security
      Test Results to record the results of the tests.  

      Step 7 - Evaluate the test results:  Once all tests are
      completed, a summary of the evaluation of the tests should
      be prepared. The team should then prepare recommendations
      about certification.  Sensitive System Certification
      Worksheet 6: Evaluation and Recommendations is used to
      record the evaluation of test results and the team's
      recommendation.  The recommendation section should be signed
      by all members of the team and dated.  
          If the tests results indicate that all protection
           requirements have been met, the team can recommend
           certification with no further action required.

          The Certification Review Team may determine from the
           test results that the protection requirements were not
           met for the system.  In that case, the evaluation
           discussion of test results should explain the
           inadequacy of the controls in place.

          The team may alternatively certify that the basic
           protection requirements have been met, but recommend
           additional features be required.  This latter form of
           certification is appropriate for certifying a software
           application system which must have certain operating
           system or hardware features in place for approved
           operation.  This may also be used in recommending
           interim accreditation pending installation of some
           additional control not currently available.  

      Step 8 - Certification:  The official Certification document
      is signed by a senior management official in the system
      owning organization.  A sample certification document is
      attached as Appendix B.

      There may be situations when the need for a system is such
      that it must be put into operation before a full
      certification is possible.  In this case, the Certifying
      Official can provisionally certify the system for operation,
      possibly with some restrictions, pending specific actions to
      be completed in a predefined time frame.  This interim
      certification cannot exceed one year.  These actions should
      also be included as milestones in the security plan for the
      system.  The certification process must be flexible enough
      that it accommodates the need for operational efficiency as
      well as adequate protection of the system.

                              APPENDIX A


This Appendix contains a set of six worksheets to assist with
documenting the certification evaluation of the system.  Each
worksheet is preceded by a set of instructions and definitions
which will provide guidance for completing the evaluation and the

                          SYSTEM DESCRIPTION

Much of the information requested on Worksheet 1 is contained in
the Security Plan for the system.  To avoid having to rewrite
this information and have a ready reference to the needed
information, attach a copy of the Security Plan behind Worksheet
1.  Each worksheet contains blank lines, where information must
be entered.  This step is important to avoid confusion with other
system certification evaluation documentation. 

System Name/Title is the name of the system used in the Security
Plan for a sensitive system (Section I.B of the Security Plan). 
To avoid confusion with other certification evaluation
documentation this should be written on all worksheets.  

System ID is the unique six digit system identification number
assigned for each sensitive system in the Department.  Again, to
avoid confusion with other certification evaluation documentation
this should be written on all worksheets.

System Owner is the name of the contact person in the owning
organization who is knowledgeable about the system and protection
requirements.  It may be the person listed as Information Contact
(Section I.G) in the Security Plan.  Provide full address and
phone number, including area code, for the owner.

Developer is the name of the person who is responsible for
developing the software.  If this is a commercial application,
put the name of the organization in this space.  If there is no
developer or the developer's name is unknown, put "none" in this

General Description/Purpose is a description of the function and
purpose of the system.  This information is contained in Section
I.E of the Security Plan.

System Environment and Special Considerations is a description of
the computer and software environment of the system.  This
information is contained in Section I.F of the Security Plan.

Sensitivity of Information Handled describes why the system is

      Applicable Laws and Regulations lists any laws and
      regulations that specifically apply to this system, such as
      the Privacy Act.  This information is contained in Section
      II.A of the Security Plan.

      General Description of Information Sensitivity is a
      description of why the system is sensitive and the nature of
      that sensitivity.  This information is contained in the
      introduction to Section II.B of the Security Plan.

Description of Protection Requirements describes what makes the
system sensitive.  The descriptions of protection needs for
confidentiality, integrity, and availability are contained in
Section II.B of the Security Plan.  Write in the designated level
(high, medium, low) in the blanks provided.
                          SYSTEM DESCRIPTIONSystem Name/TitleSystem ID:
System Owner

Address:   ______________________________________________________
Phone:     ______________________________________________________
           _________Programmer/Developer:

Address:   ______________________________________________________
Phone:     ______________________________________________________
           _________General Description/Purpose
  (See Section I.E. of attached security plan.)
System Environment and Special Consideration
  (See Section I.F. of attached security plan).

Sensitivity of Information Handled:
  Applicable Laws and Regulations Affecting the System
  (See Section II.A. of attached security plan.)

General Description of Information Sensitivity
  (See Section II.B. of attached security plan.)
Description of Protection Requirements
  See Section II.B. of attached security plan and fill in the
designated level (high, medium, low) in the blanks.

Confidentiality ______

Integrity ______

Availability ______


System Name/Title and System ID are the same as on Worksheet 1.

Description of Identified Vulnerabilities should include the
vulnerabilities that the system may have prior to putting
controls in place.  These should have been identified in the risk
analysis.  They might include physical vulnerabilities such as
fire or disk crashes, entry of erroneous data, denial of service,
and unauthorized access to information.
                      IDENTIFIED VULNERABILITIESSystem Name/TitleSystem ID:
Description of Identified Vulnerabilities
  (From Risk Analysis, Security Plan, system documentation,
interviews and other review      reports - Risks that exist prior
                                 to putting any controls in place)

                           SECURITY FEATURES

System Name/Title and System ID are the same as on Worksheet 1.

Description of Security Features is a list of the security
features used to protect this system.  They can be taken from
Sections III.C of the Security Plan and include Management
Controls, Development/Implementation Controls for application
systems, Acquisition/Development/Installation Controls for
general support systems, Operational Controls, Security Awareness
and Training, Technical Controls and Complementary Controls
Provided by General Support Systems for application systems or
Controls Over the Security of Applications for general support

Although, it is not necessary to include the level of detail
contained in the Security Plan, the controls should be listed to
provide a foundation for selecting tests to be performed to
verify if the controls are adequate and appropriate and are
operating as expected.
                           SECURITY FEATURESSystem Name/TitleSystem ID:
Description of Security Features:

                            SECURITY TESTS

System Name/Title and System ID are the same as on Worksheet 1.

Test Scenarios should contain a numbered list of the tests to be
preformed to verify the controls listed on Worksheet 3.  For more
detail about the controls, see Section III.C. of the security

          If this is an existing system that has been in
           operation for some time, the tests may selectively test
           the most critical controls. 

          If the system is under, or just completed development,
           or is a turn-key system, all security controls should
           be tested.

          If testing has been done for a another recent review,
           or during recent acceptance testing of the system, it
           may not be necessary to repeat the tests.  It will be
           necessary to review records of the prior tests, and
           determine if the documentation of the tests and results
           are adequate.   If it is determined that it is not
           justified to repeat the tests, a statement should be
           included on Worksheet 4 explaining the reason.  Also,
           include enough information about all supporting
           documentation reviewed, to allow it to be located for
           future reference.  At a minimum, include a list of
           tests from the documentation, that were performed. 
           This list need not contain as much detail for each
           individual test as the referenced documentation. 

                            SECURITY TESTSSystem Name/TitleSystem ID:
Test Scenario:

                         SECURITY TEST RESULTS

System Name/Title and System ID are the same as on Worksheet 1.

Test Results reports the results of each of the tests described
on Worksheet 4.  The numbers on Worksheet 5 for each test result
should agree with the numbers on Worksheet 4 for the test
description.  Indicate whether the was "Passed" or "Failed".

                         SECURITY TEST RESULTSSystem Name/TitleSystem ID:
Test Results:


System Name/Title and System ID are the same as on Worksheet 1.

Evaluation of Test Results should discuss the results of the
tests and their relationship to assuring the adequacy of

Under Recommendations check one of the three responses.  

          Check Tests indicate that protection requirements were
           met if all tests resulted in correct results.

          Check Tests indicate that protection requirements were
           not met if some tests failed and corrections have not
           been, or cannot be implemented.

          Check Tests indicate that protection requirements were
           met; recommend certification with the following
           additional security features required: if there are
           additional security controls needed to meet the
           protection requirements.  This category should be used
           when certifying software applications that require
           hardware or operating system features to assure
           adequate protection.  It should also be used if an
           interim certification is being recommended, pending
           completion of specific actions.

Certifying Team Signatures should included printed names of the
certifying team members, a signature, and a date for each team

                    EVALUATION AND RECOMMENDATIONSSystem Name/TitleSystem
Evaluation of Test Results:


      _____      Tests indicate that protection requirements were

      _____      Tests indicate that protection requirements were
                 not met.  RECOMMEND THAT THIS SYSTEM NOT BE

      _____      Tests indicate that protection requirements were
                 met; recommend certification with the following
                 additional security features required:

Certifying Team Signatures

     Name                        Signature                      




                              Appendix B

                    Sample Certification Statement

I have carefully examined the certification worksheets for DOC
Information Technology System Number _________, "Insert system
name/title", dated ___________________ .  Based on the
information contained in this package and the results of tests
conducted on the system, it is my judgment that satisfactory
information technology controls are in place to adequately
protect the system and that it is operating at an acceptable
level of risk.  

I hereby certify DOC IT System Number ________, "Insert system
name/title", for a period not to exceed three years.  Should
substantial changes or security incidents occur during that three
year period, which bring the adequacy of the protection measures
for this system into question, a reevaluation and recertification
must be completed earlier.

Certification Official Name/Title: 


Signature: _____________________________________________  Date:


TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH