DITSCAP DESCRIPTION
 E3.1. DITSCAP
OVERVIEW
E3.1.1. The
DITSCAP establishes a standard process, set of activities, general task
descriptions, and a management structure to certify and accredit IT
systems that will maintain the security posture of the DII. The DITSCAP
focuses on protecting the DII by presenting an infrastructure-centric
approach for C&A. The DITSCAP is designed to be adaptable to any type of
IT and any computing environment and mission. The process should be
adapted to include existing system certifications and evaluated
products.
E3.1.2. The
process is designed to certify that the IT system meets the
accreditation requirements and that the system will continue to maintain
the accredited security posture throughout the system life-cycle. The
users of the process shall align the process with the program strategy
and integrate the process activities into the system life-cycle. While
DITSCAP maps to any system life-cycle process, its four phases are
independent of the life-cycle strategy.
E3.1.3. The
key to the DITSCAP is the agreement between the IT system program
manager(4),
the DAA, the CA, and the user representative. These managers resolve
critical schedule, budget, security, functionality, and performance
issues. This agreement is documented in the SSAA that is used to guide
and document the results of the C&A. The objective is to use the SSAA to
establish a binding agreement on the level of security required before
the system development begins or changes to a system are made.
(Reference
Application Document C1.1
for further information.)
E3.2. DITSCAP
PHASES
Figure E3-1. The DITSCAP. click to enlarge
E3.2.1. The
DITSCAP is composed of four phases: Definition, Verification,
Validation, and Post Accreditation. (See figure E3-1.) Phase 1,
Definition, is focused on understanding the mission, environment, and
architecture to determine the security requirements and level of effort
necessary to achieve accreditation. The objective of phase 1 is to agree
on the intended system mission, environment, architecture, security
requirements, certification schedule, level of effort, and resources
required. Phase 2, Verification, verifies the evolving or modified
system's compliance with the information agreed on in the SSAA. The
objective of phase 2 is to produce a fully integrated system ready for
certification testing. Phase 3, Validation, validates compliance of the
fully integrated system with the information stated in the SSAA. The
objective of phase 3 is to produce the required evidence to support the
DAA in making an informed decision
to grant approval to operate the system; e.g., accreditation. Phases 1,
2, and 3 are the DITSCAP process engine. Those phases are repeated as
often as necessary to produce an accredited system. Phase 4, Post
Accreditation, includes those activities necessary for the continuing
operation of the accredited IT system in its computing environment and
to address the changing threats a system faces through its life-cycle.
Phase 4 starts after the system has been certified and accredited for
operations. The objectives of phase 4 are to ensure secure system
management, operation, and maintenance to preserve an acceptable level
of residual risk.
E3.2.2. The
phases are comprised of activities. The activities include various
procedures and tasks. Each phase and activity shall be performed for
every system. The procedures and tasks in each process activity may be
tailored and scaled to the system and its associated acceptable level of
residual risk. The procedures and tasks should be tailored and
integrated with on-going systems acquisition activities to best fit the
mission, environment, system architecture, and programatic
considerations. In that manner, the process maintains flexibility to
deal with different acquisition strategies, and operational scenarios;
e.g., rapid deployment.
E.3.2.3. An
ITSEC system class structure has been established,
enclosure 7, that
groups systems into classes to allow new developments to draw on
previous experience. The system class approach makes it possible to
establish class repositories to store information on other similar C&A
efforts. As systems are certified and accredited, the approved solutions
and documentation may be filed in a class repository. When a new system
development begins, or an existing system is to be revised, the class
repository may be accessed. That will facilitate rapid determination of
system security policy and security requirements based on the group or
class into that the system falls. The repository can also provide
insight into the previous certification efforts and documentation of the
approved solutions.
E.3.2.4.
The subparagraph E3.3 through E3.6, describe the process phases,
activities, and tasks required. Enclosure 8 summarizes these process
components. Additional details on the process may be found in the IASE.
The IASE has been established to assist DITSCAP users in the use of the
DITSCAP and to support the implementation of standard C&A practices
throughout the Department of Defense. (Reference
Application Document C2.1
for further information.)
E3.3. PHASE 1
-
DEFINITION
E.3.3.1.
Phase 1 tasks define the ITSEC C&A level of effort, identify the DAA and
the CA, and culminate with an agreement, by the program manager, the DAA,
the CA, and the user representative, on the method for implementing the
security requirements. That agreement is documented in the SSAA, which
shall describe the system mission, target environment, target
architecture, security requirements, and applicable data access
policies. The SSAA shall describe the applicable set of planning and
certification actions, resources, and documentation required for the
C&A. The SSAA is the vehicle that guides the implementation of ITSEC
requirements and the resulting C&A actions. The SSAA outline,
enclosure 6,
lists information that should be included.
E.3.3.1.1.
Phase 1, figure E3-2, contains three process activities, document
mission need, registration, and negotiation. Phase 1 starts with the
input of the mission need statement (or other justification for the
system) and ends by producing the SSAA. The process activities provide
the pathway to understanding the IT system requiring C&A; documenting
the ITSEC requirements; developing a security architecture approach; and
determining the scope, level of effort, documentation required, and
schedule for the planning and certification actions. Any level of change
to existing systems shall initiate the process. During the registration
and negotiation activities, the program manager, the DAA, the CA, and
the user representative will determine what actions shall follow that
system change.
(Reference
Application Document C3.1
for further information.)
Figure E3-2. DITSCAP Phase 1 Definition Activities.
E3.3.2.
Document Mission Need. Documenting mission need is the process
activity that initializes the DITSCAP. Initialization occurs when an
information system is developed or modified in response to an identified
operational requirement or mission need. The mission need, figure E3-3,
is either a document or compilation of information stating the
requirements of the system and describing its intended capabilities.
Those capabilities include functions the system should perform, desired
interfaces and capabilities associated with those interfaces, the
information to be processed, the operational organizations supported,
the intended operational environment, and the operational threat.
Typically, the mission need is described in a high-level requirements
document before the DITSCAP is initiated.
|
Mission Need
Statement
1. System
mission, functions, and system interfaces.
2. Operational Organization.
3. Information category and classification.
4. Expected system life-cycle.
5. System users characteristics.
6. Operational environment. |
Figure E3-3. Mission
Need Security Relevant Information.
E3.3.3.
Registration. Registration is the process activity in phase 1 that
initiates the dialogue among the program manager, the DAA, the CA, and
the user representative. As part of the Registration tasks, information
is collected and evaluated, applicable ITSEC requirements are
determined, risk management and vulnerability assessment actions begin,
and the level of effort required for C&A is determined and planned.
Registration shall begin with a review of the mission need and concludes
with preparation of an initial draft of the SSAA.
|
Registration Tasks
1.
Inform the DAA, the CA, and the user representative that the system
will require C&A support; e.g., register the system.
2. Prepare mission
description and system identification. (Reference
Application Document C3.4.2
for further information.)
3. Prepare the
environment and threat description. (Reference
Application Document C3.4.4
for further information.)
4. Prepare system
architecture description and C&A boundary. (Reference
Application Document C3.4.6
for further information.)
5. Determine ITSEC system class.
6. Determine the system
security requirements. (Reference
Application Document C3.4.5
for further information.)
7. Identify organizations that will be involved in
the C&A and identify resources required.
(Reference
Application Document C3.4.7
for further information.)
8. Tailor the DITSCAP tasks, determine the C&A
level-of-effort, and prepare a DITSCAP plan.
(Reference
Application Document C3.4.8
for further information.)
9. Develop the draft
SSAA.
(Reference
Application Document C3.4.9
for further information.)Draft SSAA |
Figure E3-4. Tasks
Performed During Registration.
E3.3.3.1.
Registration tasks, figure E3-4, guide the collection of necessary
information to address the process in a repeatable, understandable, and
effective manner. Those tasks identify information necessary for
determining security requirements and the level of effort to accomplish
the C&A that is influenced by the degree of assurance needed in the
areas of confidentiality, integrity, availability, and accountability.
Registration shall consider the system development approach, system
life-cycle stage, existing documentation, mission, environment
(including the threat assessment), architecture, users, data
classification and categories, external interfaces, and mission
criticality. Mission-system relationships may vary from a single system
supporting a single mission, to a single system supporting multiple
missions, to a multiple systems supporting multiple missions, to a
multiple systems supporting a single mission. A crucial piece of
information for the accreditation is the identification of the roles
that the system shall support in the encompassing enterprise mission.
(Reference
Application Document C3.3.3.1
for further information.)
E3.3.3.2.
Most of that information can be obtained from examining the mission need
and functional requirement documents. That information is used to
determine the system class (see
enclosure 7). The
various system classes are associated with minimum-security requirements
and specific actions that shall be performed. The system class approach
establishes minimum-security requirements as a function of mission(s),
environment, and system architecture. The DITSCAP provides the
capability to normalize high-level requirements through the use of the
system class structure. The system class approach supports the
identification of other similar systems that have undergone C&A, to
analyze previously approved security requirements and solutions. That
supports the reuse of their security requirement definitions, draws from
their architecture approaches, and promotes reuse of applicable C&A
information. Determining the applicable system class is essential to the
development of the minimal security requirements necessary for the
certification and eventual accreditation of the system.
E3.3.3.3. A key
task in registration is to prepare an accurate description of the system
and its development, operating and maintenance environment under
consideration. While the details of the system or the environment may
not be clear at the onset of a system development, the system shall be
defined in enough detail to accurately portray the system's general
concept and boundaries. That description shall define what is included
in the accreditation boundary (e.g. system boundary, facilities, and
equipment), and the external interfaces with other equipment or systems.
Currently known threats shall be assessed against the specific system
mission and a description to determine the necessary protection
required. The threat, and subsequent vulnerability assessments, shall be
used in establishing and selecting the ITSEC policy objectives that will
counter the threat.
E3.3.3.4.
The key roles in the DITSCAP
are the program manager of the organization responsible for the system,
the DAA, the CA, and the user representative.
As a system progresses through the life-cycle phases, system
responsibility (engineering and funding) may change. During acquisition,
that responsibility may be the acquisition organization that will be
represented by the system's program manager. During the operations and
maintenance phase of the system, that responsibility may be the system
manager or in the case of a major upgrade, the maintenance organization
who will be represented by the upgrade program manager. The DAA is
usually a senior operational commander with the authority and ability to
evaluate the system operations in view of the security risks. The CA,
security teams, etc. are the technical experts that support the C&A
process. The system users may be part of a single organization or a
large diverse community. In either case, for DITSCAP purposes, the user
representative will represent their interests.
E.3.3.3.5.
To maintain the goal of a standard DoD process, the DITSCAP was
developed in a manner that it can readily be applied to any system
program strategy, (grand design, incremental, evolutionary, etc.) or
life-cycle management process, DoD Directive 5000.1 (reference
(i)). During phase 1, the application
of the DITSCAP shall be tailored to the system program strategy, the
life-cycle management process, and to adjust to systems that have
progressed in their life-cycle. Tailoring adapts the security tasks to
the system's life-cycle phase and program strategy. The process
generally has been described as if it were to be applied to a new system
with a grand design program strategy. In that case the DITSCAP phase 1
would be initiated during the phase 0, concept exploration and
definition phase, and tailored to support the ensuing system milestone
decisions. Legacy systems shall enter the DITSCAP process when they are
in need of compliance validation or undergo a modification that may
impact the security posture. For example, if the system is in the
operations and support phase, and the IT system is not accredited, the
DITSCAP would be initiated with phase 1. The process would be tailored,
the SAA would developed, and on agreement between the system program
manager, the DAA, the CA, and the user representative, the process would
move to applicable phase 2 and phase 3 activities. That capability
permits the certification effort to be scaled to fit the size and
complexity of the system while remaining responsive to the operational
requirements driving the information system development or modification.
The certification analysis tasks can be tailored to work with all DoD
program strategies.
(Reference
Application Document C7.1
for further information.)
E3.3.3.6.
Certification tasks, based on analysis of the characteristics of the IT
and the security requirements, are defined for each system class.
Certification tasks are grouped into four certification levels to
provide guidance on the recommended minimum tasks. Use of
enclosure 7
is strongly recommended as the method to determine the certification
level. The DAA, the CA, the program manager, and the user representative
may tailor the certification tasks and level of effort to the IT system
mission, environment, architecture, programmatic considerations, and
level of acceptable risk. For example, the three managers may choose to
condense the time scale to meet operational needs, or to use previously
approved security solutions and reduce the corresponding certification
tasks. As the system development or maintenance progresses, new issues
may emerge, and phase 1 may be revisited for new agreements or
additional tailoring. The DAA, the CA, the program manager, and the user
representative each represent different views and as such provide the
checks and balances to ensure the minimum-security requirements are met.
Therefore, it is important the SSAA be kept current to reflect each of
these tailoring decisions.
E3.3.3.7.
The SSAA is prepared during registration. The preparation of the SSAA
shall have all parties involved or represented, including the CA,
program sponsor, threat specialist, etc. When registration planning
activities are concluded, the draft is submitted to the DAA, the program
manager, and the user representative. The draft SSAA is used as a guide
to establish the basis for discussions during the negotiation activities
among the DAA, the CA, the program manager, and the user
representative.(Reference
Application Document C3.3.3
for further information.)
E3.3.4.
Negotiation. Negotiation is the process activity of the DITSCAP,
where all the participants involved in the information system's
development, acquisition, operation, security certification, and
accreditation agree on the implementation strategy to be used to satisfy
the security requirements identified during system registration. The key
parties who must reach agreement during the negotiations are the program
manager, the DAA, the CA, and the user representative.(5)
The negotiation
tasks are shown in figure E3-5.
|
Negotiation Tasks
1. Review
initial SSAA.
2. Conduct the certification requirements review.
3. Approve final SSAA. |
Figure E3-5. Negotiation
Tasks.
E3.3.4.1. A
review of the initial SSAA is performed by the DAA. The DAA shall
conduct a complete review of the draft SSAA and all aspects that may
impact C&A. The CA is responsible for the comprehensive evaluation of
the technical and nontechnical security features of the IT. The CA is
regarded as the technical expert in the discussions that consider
tradeoffs between security requirements, cost, availability, and
schedule to manage security risk.
E3.3.4.2. A
certification requirements review (CRR) shall be held for the principals
involved in the C&A process. As a minimum, the program manager, the user
representative, the DAA, and the CA shall attend the CRR. The review
shall include the information documented in the SSAA; i.e., mission and
system information, operational and security functionality, operational
environment, system class, security policy, system security
requirements, known security problems or deficiencies, and other
security relevant information. While that review may be held with other
system reviews, the intent of the CRR is to assist the organization
responsible for IT system in preparing for the certification actions.
The CRR review shall result in an agreement regarding the level of
effort and the approach that will be taken to implement the security
requirements.
E3.3.4.3.
Negotiation is NOT a consideration of which security requirements to
implement and which to delete. For example, any system connected to the
DII, or any network, shall comply with the connection rules for those
systems that it is to be connected. The purpose of negotiation is to
ensure that all participants understand their roles and responsibilities
and that the SSAA properly and clearly defines the approach and level of
effort. Negotiation ends when the responsible organizations adopt the
SSAA and concur that those objectives have been reached.
(Reference
Application Document C3.3.4
for further information.)
E3.3.5.
SSAA. The objectives of the SSAA, shown in figure E3-6, are to
document the conditions of C&A for an IT system. The SSAA is a formal
agreement among the DAA(s), the CA, the IT system user representative,
and the program manager. It is used throughout the entire DITSCAP to
guide actions, document decisions, specify ITSEC requirements, document
certification tailoring and level of effort(6), identify
possible solutions, and maintain operational systems security. The SSAA
shall identify all costs relevant to the C&A process and the program
manager shall add a C&A funding line item to the program budget to
ensure the funds are available. Funding shall cover any travel or
program contractor costs associated with certification, test
development, testing and accreditation. Where multiple accreditors may
be involved, an agreement between the accreditors may be necessary. That
agreement must be included with the SSAA. Since the SSAA is an agreement
among Government entities, to be binding on the government's
contractors, the provisions must be included in contractual documents
between the Government and any contractors.
|
SSAA
1. Document
the formal agreement among the DAA(s), the CA, the user
representative, and the program manager.
2. Document all requirements necessary for
accreditation.
3. Document all security criteria for use throughout
the IT system life-cycle.
4. Minimize documentation requirements by
consolidating applicable information into the SSAA (security policy,
concept of operations (CONOPS), plans, architecture description,
etc.).
5. Document the DITSCAP plan. |
Figure E3-6. SSAA
Objectives.
E3.3.5.1.
The SSAA is intended to reduce the need for extensive documentation by
consolidation of security related documentation into one document. That
eliminates the redundancy and potential confusion as multiple documents
describe the system, security policy, system and security architecture,
etc. When feasible, the SSAA can be tailored to incorporate other
documents as appendices or by reference to the pertinent document. An
outline of the SSAA is found in
enclosure 6.
E3.3.5.2. Each IT
system shall have a SSAA. The physical characteristics of the SSAA will
depend on the system class and level of effort needed for C&A. The SSAA
can be as simple as a single coordinated message or as complex as a
detailed system security plan. For generic accreditation's, a single
SSAA may be prepared for the system, but the description of the
operating environment will need to reflect each proposed operation
location. The goal is to produce a SSAA that will be the basis of
agreement throughout the system's life-cycle.
E3.3.5.3.
The four parties to the negotiation have the authority to tailor the
SSAA to meet the characteristics of the IT, operational requirements,
security policy, and prudent risk management. The SSAA must be flexible
enough to permit adjustment throughout the system's life-cycle as
conditions warrant. New requirements may emerge from design necessities,
existing requirements may need to be modified, or the DAA's overall view
of acceptable risk may change. When that occurs, the program manager,
the DAA, the CA, and the user representative shall ensure the SSAA is
updated to accommodate the new components. Common sense must be applied
to the rules. The SSAA is developed in phase 1 and updated in each phase
as the system development progresses and new information becomes
available. In this sense, the SSAA is regarded as a living document. The
completed SSAA contains those items that must be
agreed on by the DAA, the CA, the
user representative, and the program manager. The support organizations
must understand each of these essential items.(Reference
Application Document C3.2
for further information.)
E3.4.
Phase 2 - Verification
The process activities of phase 2 verify the
evolving system's compliance with the requirements agreed on in the SSAA.
(See figure E3-7.) That phase consists of those process activities that
occur between the signing of the initial version of the SSAA and the
formal C&A of the system. Phase 2 process activities include continuing
refinement of the SSAA, system development or modification,
certification analysis, and analysis of the certification results.
(Reference
Application Document C4.1
for further information.)
E3.4.1.
Refine the SSAA. Phase 2 starts with a review of the SSAA. All
participants shall at minimum, read the SSAA. A detailed review shall be
completed if there has been considerable time delay since the completion
of phase 1, or if new people are now involved in the C&A. That review
continues throughout phase 2 as the development or modification of the
system progresses. At each stage of the development or modification, the
SSAA shall be refined by adding details to reflect the current state of
the system. Any changes in the system that affect its security posture
must be submitted to the DAA, the CA, the program manager, and the user
representative for approval and execution in the revised SSAA. As the
development or modification progresses and specific information on to
the certification effort becomes available, the SSAA shall be updated to
include more specific details. At each subsequent stage of the IT
system's development or modification, increasing details about the
hardware and software architecture become available. That design
information shall be added to the SSAA as justification to support the
agreed on level of certification actions.
(Reference
Application Document C4.2.1
for further information.)
Figure E3-7. DITSCAP Phase 2, Verification Activities.
E3.4.2.
System Development Activity. System development activities are those
activities required to develop and integrate the IT system components.
The specific activities are a function of the overall program strategy,
the life-cycle management process, and the position of the information
system in the life-cycle. The certification analysis activity in phase 2
is intended to ensure that the requirements of the SSAA are followed
during each life-cycle phase of the development and modification of the
information system. Each system development activity task has a
corresponding phase 2 certification analysis task. The system
development activity and certification analysis tasks ensure that the
requirements in the SSAA are met.
(Reference
Application Document C4.2.2
for further information.)
E3.4.3.
Certification Analysis. Certification analysis is the process
activity that determines if the IT system is ready to be evaluated and
tested under phase 3, validation. Because the DITSCAP is a
success-oriented process, this process activity ensures that the
development, modification, and integration efforts will result in a
certifiable and accreditable information system before phase 3 begins.
E3.4.3.1. The
certification analysis tasks that occur during the process activity,
certification analysis, are shown in figure E3-8. Those certification
tasks verify by analysis, investigation, and comparison methodologies
that the IT design implements the SSAA requirements and that the IT
components that are critical to security function properly. Those tasks
compliment the functional testing certification tasks that occur during
phase 3. While every system may be considered certifiable, the goal is
to produce systems with an acceptable level of risk.
|
Certification Tasks
1. System
architecture analysis.
2. Software design analysis.
3. Network connection rule compliance analysis.
4. Integrity analysis of integrated products.
5. Life-cycle management analysis.
6. Vulnerability assessment. |
Figure E3-8.
Certification Tasks During Verification.
E3.4.3.2. As a
result of completion of the phase 2 certification analysis, the system
should have a documented security specification, a comprehensive test
plan, and written assurance that all network and other interconnections
requirements have been implemented. Commercial off-the-shelf (COTS) and
government off-the-shelf (GOTS) products used in the system design shall
have been validated to assure that they have been integrated properly
and that their functionality meets the security needs of the system. A
vulnerability assessment will have been conducted and will have
concluded that the infrastructure needs of the system; e.g.,
configuration management, will be accommodated throughout the IT
life-cycle. On acceptance of the vulnerability assessment, the C&A task
proceeds to phase 3, that contains the formal system certification test
and security accreditation actions.
E3.4.3.3.
All analysis tasks, applicable for that system class, are to be
completed. The intensity of the certification analysis tasks are scaled
to the complexity of the IT design, the sensitivity of the information
processed, and the criticality of the information system's intended
mission. The specific certification tasks may be tailored to the IT
program strategy, its life-cycle management process, and the position of
the information system in its life-cycle. Certification tasks are
tailored to the system development activities to ensure that the former
are relevant to the process and provide the required degree of analysis
to ensure conformance with the SSAA. Tailoring also gives DITSCAP the
flexibility to adjust the level of effort to fit the operational need.
In that manner, tailoring permits the DITSCAP to remain responsive to
national agency and military department priorities. Phase 2
certification tasks may vary from completion of a
minimal checklist
to in-depth analysis as determined by the system class. The
certification tasks are discussed in paragraphs E3.4.3.3.1 through
E3.4.3.3.6 below.
(Reference
Application Document C4.2.3
for further information.)
E3.4.3.3.1.
System Architecture Analysis. The objective of this certification
task is to ensure that the system architecture complies with the
architecture description agreed on in the SSAA. Analysis of system level
information reveals how effectively the security architecture implements
the security policy and requirements. The interfaces between this and
other systems shall be identified. Those interfaces must be evaluated to
assess their effectiveness in maintaining the security posture of the
infrastructure.
(Reference
Application Document C4.3.2
for further information.)
E3.4.3.3.2.
Software Design Analysis. The software design certification task
shall evaluate how well the software reflects the security requirements
of the SSAA and the security architecture of the system. That
certification task may include a detailed analysis of software
specifications and software design documentation. The TCB shall be
identified and analyzed for proper and full implementation of the
security requirements. The task shall assess whether the critical
security features e.g., identification and authentication, access
controls, and auditing, are implemented correctly and completely.
(Reference
Application Document C4.3.3
for further information.)
E3.4.3.3.3.
Network Connection Rule Compliance Analysis. The connection of an
information system to a network requires that the particular system will
not adversely affect the security posture of the network. Connection
also requires that the network will not adversely affect the IT system's
own security posture. That certification task evaluates the intended
connections to other systems and networks to ensure the system design
will enforce specific network security policies and protect the IT
system from adverse confidentiality, integrity, availability, and
accountability impacts.
E3.4.3.3.3.1. Network analysis may include the evaluation of intended
interfaces for compliance with the security connection rules not only
for the network, but also for the information system. The system concept
of operations (SSAA section 1) shall be examined to identify all the
connections and interfaces intended for the system. It is important to
determine if connections exist that were not in the initial concept, but
are to be added after the initial fielding or modification of the
system. The interfaces to the networks or to other systems shall be
evaluated to determine if the system and network security can be
maintained at both ends of the interface. They also shall be evaluated
to ensure that end-to-end connection constructs are maintained and
security connection rules are applied. Test plans and procedures shall
be developed to validate compliance with the network connection
rules.(Reference
Application Document C4.3.4
for further information.)
E3.4.3.3.4.
Integrity Analysis of Integrated Products (COTS, GOTS, or
Non-Developmental Item (NDI)). This certification task evaluates the
integration of COTS, GOTS, or NDI software, hardware, and firmware to
ensure that their integration into the system design complies with the
system security architecture, and the integrity of each product is
maintained.
E3.4.3.3.4.1. Integrated product analysis shall include the
identification, and may include the verification of the security
functionality, of each product. That certification task shall determine
whether or not evaluated products are being used for their intended
purpose. Integrity product analyses shall include an examination of the
system and subsystem interfaces, information flows, and applicable use
of selectable product features. All interfaces and information flows are
examined to identify how they access the products.
(Reference
Application Document C4.3.5
for further information.)
E3.4.3.3.5.
Life-Cycle Management Analysis. This certification task ensures that
change control and configuration management practices are, or will be,
in place and are sufficient to preserve the integrity of the security
relevant software and hardware. During the system development, or
maintenance, the development approach, procedures, and engineering
environment are assessed and the life-cycle plans are evaluated.
Proposed contingency, continuity of operations, and back-up plans shall
be evaluated for feasibility. That may require examining the following
types of documents or procedures shown in figure E3-9.
|
Life-Cycle
Management Documentation
1. Computer
Resource Management Plan (CRMP).
2. Computer Resources Life-Cycle Management Plan (CRLCMP).
3. Configuration identification procedures.
4. Configuration control procedures.
5. Configuration status accounting procedures.
6. Configuration audit procedures and reports.
7. Software engineering (development approach and
engineering environment) procedures.
8. Trusted distribution plans.
9. Contingency, continuity of operations, and
back-up plans. |
Figure E3-9. Life-Cycle
Management Documentation.
(Reference
Application Document C4.3.6
for further information.)
E3.4.3.3.6.
Vulnerability Assessment. This certification task shall evaluate
security vulnerabilities with regard to confidentiality, integrity,
availability, and accountability and recommends applicable
countermeasures. The DAA should determine the acceptable level of risk
to protect the system commensurate with its value to the Department of
Defense.(7)
In phase 2, the
vulnerability assessment concentrates on the progress in implementing
the security requirements of the SSAA. It reviews the SSAA at the
beginning of phase 2 and concludes with notifying the CA and the DAA
that the information system is ready for C&A evaluation and testing.
E3.4.3.3.6.1.
During vulnerability assessment, each of the vulnerabilities and
discrepancies isolated during the evaluation of the system architecture,
system design, network interfaces, product integration, and
configuration management practices is analyzed to determine its
susceptibility to exploitation, the potential rewards to the exploiter,
the probability of occurrence, and any related threat. The analysis
should use techniques such as static penetration, or active penetration
testing to determine the ability to exploit the vulnerabilities. The
residual risk, that portion of risk that remains after security measures
have been applied, shall be determined by ranking the evaluated
vulnerabilities against threat, ease of exploitation, potential rewards
to the exploiter, and a composite of the three areas. All residual risks
shall be identified and evaluated. The evaluation shall indicate the
rationale as to why the risk should be accepted or rejected, and the
operational impacts associated with these risks.
E3.4.3.3.6.2. Coordination among the program manager, the DAA, the CA,
and the user representative ensures that the residual risk does not
exceed the level of risk established by the DAA. That level of risk that
shall now be documented in the SSAA is called the "acceptable level of
residual risk." If the risk exceeds the maximum acceptable risk, the
system shall fail the C&A.
(Reference
Application Document C4.3.8
for further information.)
E3.4.4.
Assess Analysis Results. At the conclusion of each life-cycle
development milestone, the certification analysis results are reviewed
for SSAA compliance. If the results indicate significant deviation from
the SSAA, the DITSCAP shall revert to phase 1 to resolve the problems.
If the results are acceptable, the DITSCAP proceeds to the next
development task or to government acceptance and security testing; i.e.,
DITSCAP phase 3.
(Reference
Application Document C4.2.4
for further information.)
Figure E3-10. DITSCAP Phase 3, Validation Activities.
E3.5.
Phase 3 - Validation
Phase 3 process activities, shown in figure
E3-10, validate that the preceding work has produced an information
system that operates in a specified computing environment with an
acceptable level of residual risk. This phase consists of process
activities that occur after the system is integrated and culminates in
the accreditation of the IT system. Phase 3 includes a review of the
SSAA, an evaluation of the integrated IT system, certification, and accreditation.(Reference
Application Document C5.1
for further information.)
E3.5.1.
Refine the SSAA. Phase 3 begins with a review of the SSAA to ensure
that its requirements and agreements still apply. That review shall
continue throughout phase 3 as the integrated system is subjected to
successive levels of evaluation. At each stage of the integrated IT
system's acceptance, the SSAA shall be refined by adding details to
reflect the current state of the system. Required changes shall be
submitted to the DAA, the CA, the program manager, and the user
representative so that the revised agreement may be approved and
executed. (Reference
Application Document C5.2.1
for further information.)
E3.5.2.
Certification Evaluation of the Integrated System. This process
activity is to certify that the fully integrated and operational system
complies with the requirements stated in the SSAA and may be operated
with an acceptable level of residual risk. During this process activity,
certification tasks, shown in figure E3-11 are performed on the
integrated operational system to ensure that the IT system is
functionally ready for operational deployment. The certification tasks
and the extent of the tasks will depend on the level of certification
analysis agreed on in the SSAA.
E3.5.2.1.
Phase 3 certification tasks shall include certification of the software,
firmware, and hardware and inspections of operational sites to ensure
their compliance with the physical security, procedural security,
TEMPEST, and COMSEC requirements. Phase 3 includes tasks to certify the
compatibility of the computing environment with the description provided
in the SSAA. DITSCAP flexibility permits the certification actions to be
scaled to the type of IT system being evaluated and tailored to the
program strategy used in the development or modification of the system.
Subparagraphs E3.5.2.1.1. through E3.5.2.8. describe the certification
tasks that may be included in the evaluation of the integrated system.
(Reference
Application Document C5.2.2
for further information.)
|
Certification Tasks
1. Security
Test and Evaluation.
2. Penetration testing.
3. TEMPEST and Red-Black verification.
4. Validation of COMSEC compliance.
5. System management analysis.
6. Site accreditation survey.
7. Contingency plan evaluation.
8. Risk-based management review. |
Figure E3-11.
Certification Tasks During Validation.
E3.5.2.1.1.
System Security Test and Evaluation. The objective of the ST&E is to
assess the technical and non-technical implementation of the security
design and to ascertain that security features affecting
confidentiality, integrity, availability, and accountability have been
implemented in accordance with the SSAA, and perform properly. System
ST&E shall validate the correct implementation of identification and
authentication, audit capabilities, access controls, object reuse,
trusted recovery, and network connection rule compliance. Individual
tests shall evaluate system conformance with the requirements, mission,
environment, and architecture defined in the SSAA. Test plans and
procedures shall address all the security requirements and the results
of the testing will provide sufficient evidence of the amount of
residual risk. These results shall validate the proper integration and
operation of all security features.
E3.5.2.1.1.1. When a system is deployed to multiple locations, the ST&E
may occur at a central integration and test facility. When use of such a
facility is not possible, the integrated system may be tested at one of
the intended-operating sites. Software and hardware security tests of
common system components at multiple sites are not recommended. The
system installation and security configuration should be tested at
operational sites.
(Reference
Application Document C5.3.2
for further information.)
E3.5.2.1.2.
Penetration Testing. For applicable system classes, penetration
testing is strongly recommended to assess the system's ability to
withstand intentional attempts to circumvent system security features by
exploiting technical security vulnerabilities. Penetration testing may
include insider and outsider penetration attempts based on common
vulnerabilities for the technology being used.
(Reference
Application Document C5.3.3
for further information.)
E3.5.2.1.3.
TEMPEST and Red-Black Verification. TEMPEST and Red-Black
verification may be required to validate that the equipment and site
meet the security requirements. In these situations the site may be
inspected to determine if adequate practices are being followed, and the
equipment may be subjected to TEMPEST testing.(Reference
Application Document C5.3.4
for further information.)
E3.5.2.1.4.
Validation of COMSEC Compliance. This certification task
validates that COMSEC approval has been granted and approved COMSEC key
management procedures are used. COMSEC analysis evaluates how well the
SSAA defined COMSEC requirements are integrated into the system
architecture and the site management procedures.(Reference
Application Document C5.3.5
for further information.)
E3.5.2.1.5.
System Management Analysis. The system management infrastructure
shall be examined to determine whether it adequately supports the
maintenance of the environment, mission, and architecture described in
the SSAA. Infrastructure components, that may provide insight into
security of operations at the site, include the system and security
management organizations, security training and awareness, and the
configuration management organization and processes. The roles and
responsibilities assigned to ISSO shall be examined to ensure that the
responsibilities are consistent with the procedures identified in the
SSAA. The system and security management organization shall be examined
to determine the ability of the ISSO to report security incidents and
implement security changes.
E3.5.2.1.5.1.
Knowledge of the security management structure may provide insight into
the emphasis the organization places on secure operation of the
computing environment. It also shall provide an indication of
effectiveness of the security personnel. Security training and awareness
shall be examined to provide insight into potential security problem
areas.
E3.5.2.1.5.2. An effective configuration management program is mandatory
if an established secure posture is to be maintained. This certification
task evaluates the change control and configuration management practices
to determine their ability to preserve the integrity of the security
relevant software and hardware. A system baseline that identifies all
information hardware, software, and firmware components and external
interfaces, provides for future security evaluations and establishes a
known reference point from which to make future accreditation decisions.
Configuration management practices shall include periodic reverification
of the system configuration to ensure unauthorized changes have not
occurred. (Reference
Application Document C5.3.6
for further information.)
E3.5.2.1.6.
Site Accreditation Survey. The site accreditation survey task
shall ensure that the site operation of the information system is
accomplished in accordance with the SSAA. The site accreditation survey
shall validate that the operational procedures for the IT, environmental
concerns, and physical security pose no unacceptable risks to the
information being processed. Where the IT system may not be confined to
a fixed site; i.e., tactical or mobile systems and embedded system in
ships or aircraft, the IT system shall be examined in representative
sites or environments.
(Reference
Application Document C5.3.7
for further information.)
E3.5.2.1.7.
Contingency Plan Evaluation. The contingency plan evaluation task
analyzes the contingency, back-up, and continuity of service plans to
ensure the plans are consistent with the requirements identified in the
SSAA. Periodic testing of the contingency plan is required by DoD
Directive 5200.28 (reference
(a)) for critical systems and is
encouraged for all systems.
(Reference
Application Document C5.3.8
for further information.)
E3.5.2.1.8.
Risk Management Review. The risk-based management review task
assesses the operation of the system to determine if the risk to
confidentiality, integrity, availability, and accountability is being
maintained at an acceptable level. The risk management review shall
assess the system vulnerabilities with respect to the documented threat,
ease of exploitation, potential rewards, and probability of occurrence.
The operational procedures and safeguards shall be evaluated to
determine their effectiveness and ability to offset risk. This is the
final review before developing the recommendation to the DAA.(Reference
Application Document C5.3.9
for further information.)
E3.5.3.
Develop Recommendation to the DAA. This process activity begins
after completion of all certification tasks and ends with the
accreditation decision by the DAA. The purpose is to consolidate the
findings developed during certification of the integrated system, submit
the CA's report to the DAA, and produce the DAA accreditation decision.
E3.5.3.1. CA's
Recommendation. If the CA concludes that the integrated IT satisfies
the SSAA technical requirements, the CA issues a system certification.
That is a certification that the IT system has complied with the agreed
on security requirements. Supplemental recommendations also might be
made to improve the system's security posture. Such recommendations
should provide input to future system enhancements and change management
decisions.
E3.5.3.1.1. In
some cases, the CA may uncover security deficiencies, but continue to
believe that the short-term system operation will present no
unacceptable risks. The CA may recommend accreditation with the
understanding that deficiencies will be corrected in a specified period.
These deficiencies shall be reflected in the SSAA and an agreement
obtained on the conditions under which the system may be operated and
the date by when the deficiencies will be remedied.
E3.5.3.1.2.
If the CA determines that the system does not satisfy the SSAA and that
short-term risks are unacceptable, the CA shall recommend that the IT
system not be accredited.
(Reference
Application Document C5.2.3
for further information.)
E3.5.4. DAA
Accreditation Decision. The CA's recommendation, the DAA
authorization to operate, supporting documentation, and the SSAA form
the accreditation package. The supporting documentation may vary between
system classes. That documentation, at minimum, shall include security
findings and deficiencies and risks of operation. The accreditation
package must contain all information necessary to support the
recommended decision. If the decision is to accredit, the decision shall
include the security parameters under which the information system in
its computing environment is authorized to operate. If the system does
not meet the requirements stated in the SSAA, but mission criticality
mandates that the system become operational, a temporary approval may be
issued. Use of the temporary approval requires a return to phase 1 to
negotiate accepted solutions, schedule, necessary security actions, and
milestones.
E3.5.4.1. When
the system accreditation has been issued, the acquisition organization
normally will move the responsibility for the SSAA to the system
operator or the maintenance organization for the information system.
When a decision is made to accredit the system, the DITSCAP begins phase
4. If the DAA withholds accreditation, the decision shall state the
specific reasons for denial and, if possible, provide suggested
solutions. The DITSCAP then reverts to phase 1 to resolve the issues.
E3.5.4.2.
Since it is difficult to accredit mobile systems at all possible
locations, the DAA may issue a generic accreditation for a typical
operating environment. The generic accreditation is the official
authorization to employ identical copies of a system in a specified
environment. The SSAA shall be modified to include a statement of
residual risk and clearly define the intended operating environment. The
SSAA shall identify specific uses of the system, operational constraints
and procedures under which this system may be operated. In that case the
DAA would include a statement with the accreditation, such as, "This
system is supplied with a generic accreditation. With the generic
accreditation, the operators assume the responsibility to monitor the
environment for compliance with the environment as described in the
accreditation documentation."(Reference
Application Document C5.2.4
for further information.)
E3.6. Phase 4
- Post Accreditation
E3.6.1. Phase 4
contains process activities necessary to continue to operate and manage
the system so that it will maintain an acceptable level of residual
risk, figure E3-12. Post-accreditation process activities shall include
ongoing maintenance of the SSAA, system operations, change management,
and compliance validation.
E3.6.1.1. Phase 4
begins after the system has been integrated into the operational
computing environment and accredited. Phase 4 shall continue until the
information system is removed from service, a major change is planned
for the system, or a periodic compliance validation is required. In the
first case, the DITSCAP responsibilities of the acquisition organization
shift to the system manager or designated maintenance organization. In
the other two cases, the DITSCAP reverts to phase 1.
Figure E3-12. DITSCAP Phase 4, Post Accreditation.
(Reference
Application Document C6.1
for further information.)
E3.6.2.
Maintenance of the SSAA. As in the preceding phases, the SSAA shall
be kept current. Phase 4 shall begin with a review of the SSAA to ensure
that all requirements and agreements are still applicable. The user
representative, the DAA, the CA, and the program manager must approve
revisions to the SSAA. On approval the necessary changes to the mission,
environment, and architecture are documented in the SSAA. Figure E3-13
summarizes the SSAA maintenance tasks.
(Reference
Application Document C6.3.2
for further information.)
|
SSAA Maintenance
Tasks
1. Review SSAA.
2. Obtain approval of changes.
3. Document changes. |
Figure E3-13. SSAA
Maintenance Tasks.
E3.6.3. System
Operation. The second process activity of phase 4, system operation,
concerns the secure operation of the IT system and the associated
computing environment, figure E3-14. System maintenance tasks ensure
that the IT system continues to operate within the stated parameters of
the accreditation. Secure system management depends on the organization
and its procedures. Site operations staff and the ISSO are responsible
for maintaining an acceptable level of residual risk. That is done by
addressing security considerations when changes are made to either the
information system baseline or to the baseline of the computing
environment operational site. The ISSO is responsible for determining
the extent that a change affects the security posture of either the
information system or the computing environment, for obtaining approval
of security-relevant changes, and for documenting the implementation of
that change in the SSAA and site operating procedures. Users are
responsible for operating the system under the security guidelines
established in the SSAA.
|
System Operation
Tasks
1. System
maintenance.
2. System security management.
3. Contingency planning. |
Figure E3-14. System
Operation Tasks.
E3.6.3.1. Secure
system management is an ongoing process that manages risk against the
IT, the computing environment, and its resources. Effective management
of the risk continuously evaluates the threats that the system is
exposed, evaluates the capabilities of the system and environment to
minimize the risk, and balances the security measures against cost and
system performance. Secure system management preserves the acceptable
level of residual risk based on the relationship of mission,
environment, and architecture of the information system and it's
computing environment. Secure system management is a continuous review
and approval process that involves the users, ISSOs, acquisition or
maintenance organizations, and the DAA.
E3.6.3.2.
Contingency planning is the task that develops a plan for emergency
response, backup operations, and post-disaster recovery. That task shall
ensure the availability of critical resources that will support the
continuity of operations in an emergency situation. The operations and
maintenance organizations, with the knowledge and approval of the ISSO,
should develop contingency plans.
(Reference
Application Document C6.2.1
for further information.)
E3.6.4. Change
Management. After an IT system is approved for operation in a
specific computing environment, changes to the IT system and the
computing environment must be controlled, figure E3-15. While changes
may adversely affect the overall security posture of the infrastructure
and the IT system, change is ongoing as it responds to the needs of the
user and new technology developments. As the threats become more
sophisticated or focused on a particular asset, countermeasures must be
strengthened or added to provide adequate protection. Therefore, change
is required to maintain an acceptable level of residual risk.
|
Change Management
Tasks
1. Support
system configuration management.
2. Risk-based management review |
Figure E3-15. Change
Management Tasks.
E3.6.4.1.
Accreditation is based on security assumptions that tie certified
hardware and software of each system to the configuration of the
computing environment. Changes in the information system configuration,
operational mission, computing environment, or to the computing
environment's configuration may invalidate the security assumptions.
E3.6.4.2.
The ISSO and system users shall support the system configuration
management process. They shall be involved in the change management
process to ensure that changes do not have an adverse affect on the
security posture of the system and it's associated IT. The strategy for
managing change shall be defined in the SSAA. The ISSO shall review and
approve changes relating to security and document the implementation of
a change in the SSAA. Changes that significantly affect the system
security posture must be forwarded to the DAA, the CA, the user
representative, and the program manager (phase 1 of the DITSCAP).
(Reference
Application Document C6.3.7
for further information.)
E3.6.5.
Compliance Validation. Periodic review of the operational system and
its computing environment shall occur at the predefined intervals,
defined in the SSAA.(8)The
purpose of this process activity, figure E3-16, is to ensure the
continued compliance with the security requirements, current threat
assessment, and concept of operations as stated and agreed on in the
SSAA. The compliance review should ensure that the contents of the SSAA
adequately address the functional environment into which the IT has been
placed.
(Reference
Application Document C6.2.2
for further information.)
|
Compliance
Validation Tasks
1. Physical
security analysis.
2. Review the SSAA.
3. Risk-based management review.
4. Procedural analysis.
5. Compliance reverification. |
Figure E3-16. Compliance
Validation Tasks.
(Reference
Application Document C6.3.9
for further information.)
|
