U. S. DEPARTMENT OF COMMERCE
ABBREVIATED CERTIFICATION
METHODOLOGY
GUIDELINES
FOR SENSITIVE AND CLASSIFIED
INFORMATION TECHNOLOGY
SYSTEMS
December 1, 1992
U. S. DEPARTMENT OF COMMERCE
ABBREVIATED CERTIFICATION METHODOLOGY
FOR SENSITIVE INFORMATION TECHNOLOGY SYSTEMS
A. INTRODUCTION
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.
B. PURPOSE
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.
C. ABBREVIATED CERTIFICATION METHODOLOGY
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.
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,
including:
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.
users
Representatives from as many of these organizations as
possible should be included on the Certification Review
Team.
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
vulnerabilities
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.
Definitions
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,
etc.
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
understood.
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
vulnerabilities.
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
SENSITIVE SYSTEM CERTIFICATION WORKSHEETS
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
worksheet.
DIRECTIONS FOR COMPLETING WORKSHEET 1:
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
space.
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
sensitive.
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.
SENSITIVE SYSTEM CERTIFICATION WORKSHEET 1
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 ______
DIRECTIONS FOR COMPLETING WORKSHEET 2:
IDENTIFIED VULNERABILITIES
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.
SENSITIVE SYSTEM CERTIFICATION WORKSHEET 2
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)
DIRECTIONS FOR COMPLETING WORKSHEET 3:
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
systems.
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.
SENSITIVE SYSTEM CERTIFICATION WORKSHEET 3
SECURITY FEATURES System Name/Title System ID:
Description of Security Features:
DIRECTIONS FOR COMPLETING WORKSHEET 4:
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
plan.
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.
SENSITIVE SYSTEM CERTIFICATION WORKSHEET 4
SECURITY TESTS System Name/Title System ID:
Test Scenario:
DIRECTIONS FOR COMPLETING WORKSHEET 5:
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".
SENSITIVE SYSTEM CERTIFICATION WORKSHEET 5
SECURITY TEST RESULTS System Name/Title System ID:
Test Results:
DIRECTIONS FOR COMPLETING WORKSHEET 6:
EVALUATION AND RECOMMENDATIONS
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
controls.
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
member.
SENSITIVE SYSTEM CERTIFICATION WORKSHEET 6
EVALUATION AND RECOMMENDATIONS System Name/Title System
ID:
Evaluation of Test Results:
Recommendations:
_____ Tests indicate that protection requirements were
met.
RECOMMEND CERTIFICATION OF THIS SYSTEM.
_____ Tests indicate that protection requirements were
not met. RECOMMEND THAT THIS SYSTEM NOT BE
CERTIFIED.
_____ Tests indicate that protection requirements were
met; recommend certification with the following
additional security features required:
Certifying Team Signatures
Name Signature
Date
_______________________________________________________________
____________
_______________________________________________________________
____________
_______________________________________________________________
____________
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
