||DoDI 5200.40: DoD Information Technology Security Certification and Accreditation Proc
Figure E3-4. Tasks Performed
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.
E18.104.22.168. 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.
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.
3. Prepare the environment and threat description.
4. Prepare system architecture description and C&A boundary.
5. Determine ITSEC system class.
6. Determine the system security requirements.
7. Identify organizations that will be involved in the C&A and identify resources required.
8. Tailor the DITSCAP tasks, determine the C&A level-of-effort, and prepare a DITSCAP plan.
9. Develop the draft SSAA. Draft SSAA
E22.214.171.124. 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 E7). 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.
E126.96.36.199. 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
E188.8.131.52. 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
E.184.108.40.206. 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.
E220.127.116.11. 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
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.
E18.104.22.168. 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