[ Pobierz całość w formacie PDF ]
architectures and standards, employing system and software engineering methodologies, security
engineering principles, and secure coding techniques. DoD recommended security control
implementation guidance is available on the KS.
(c) The ISO or PM/SM must ensure early and ongoing involvement by IS security
engineers qualified in accordance with DoD 8570.01-M (Reference (aa)). Mission owner(s) must
translate security controls into system specifications, ensure the successful integration of those
specifications into the system design, and ensure security engineering trades do not impact the
ability of the system to meet the fundamental mission requirements. This includes ensuring that
technical and performance requirements derived from the assigned security controls are included
in requests for proposals and subsequent contract documents for design, development,
production, and maintenance.
(d) The proposed system security design must be addressed in preliminary and
critical design reviews. System security design should address security controls that may be
satisfied through inheritance of common controls. In addition, mandatory configuration settings
are established and implemented on IT products in accordance with federal and DoD policies.
31 ENCLOSURE 6
DoDI 8510.01, March 12, 2014
(e) PMs for programs acquiring IS or PIT systems in accordance with Reference (s)
must integrate the security engineering of cybersecurity requirements and cybersecurity testing
considerations into the program s overall systems engineering process, and document and update
this approach in the program s systems engineering plan and PPP throughout the system
development lifecycle.
(2) Document the security control implementation in accordance with DoD
implementation guidance found on the KS, in the security plan, providing a description of the
control implementation (including planned inputs, expected behavior, and expected outputs) if
not in accordance with the KS guidance. See the KS for specific control documentation
requirements, including required artifacts, templates, and best practices.
(3) Security controls that are available for inheritance (e.g. common controls) by IS and
PIT systems will be identified and have associated compliance status provided by hosting or
connected systems.
d. Step 4 - Assess Security Controls
(1) Develop, review, and approve a plan to assess the security controls. An assessment
methodology consistent with Reference (j) is provided in the KS as a model for use or
adaptation. DoD Components will use this model, or justify the use of another risk assessment
methodology within the Component, to include addressing understanding of the impact on
reciprocity across the federal, Intelligence, and DoD communities. The risk assessment will be
used by the SCA to determine the level of overall system cybersecurity risk and as a basis for a
recommendation for risk acceptance or denial to the AO. The SCA develops the security
assessment plan, and the AO or AODR reviews and approves the plan. PMs of programs
acquiring IS and PIT systems, in concert with the SCA and the program s T&E, working-level
integrated product team, must:
(a) Ensure security control assessment activities are coordinated with the following:
interoperability and supportability certification efforts; DT&E events; OT&E events.
(b) Ensure the coordination of activities is documented in the security assessment
plan and the program T&E documentation , to maximize effectiveness, reuse, and efficiency.
Where appropriate, integrated testing should include the evaluation of survivability, assessment
of controls, and certification testing, as well as developmental and OT&E.
(2) Assess the security controls in accordance with the security assessment plan and DoD
assessment procedures. Assessment procedures are used to verify that a security control has
been properly implemented. SRG and STIG compliance results will be documented and used as
part of the overall security control assessment. The KS is the authoritative source for security
control assessment procedures. Actual results are recorded in the SAR and POA&M as part of
the security authorization package, along with any artifacts produced during the assessment (e.g.,
output from automated test tools or screen shots that depict aspects of system configuration). For
inherited security controls, assessment test results and supporting documentation are maintained
by the providing system and are made available to SCAs of receiving systems on request. For
32 ENCLOSURE 6
DoDI 8510.01, March 12, 2014
common controls inherited from the enterprise, instructions for documenting compliance are
provided on the KS. SCAs will maximize the reuse of existing assessment (i.e., a leveraged
authorization), and T&E documentation in their assessment of the system.
(a) Record Security Control Compliance Status. If no vulnerabilities are found
through the process of executing the assessment procedures, the security control is recorded as
compliant. If vulnerabilities are found, the control is recorded as NC in the POA&M, with
sufficient explanation. Security controls that are not technically or procedurally relevant to the
system, as determined by the AO, will be recorded as not applicable (NA) in the POA&M, with
sufficient justification. The status and results of all security control assessments in the control
set (see paragraph 2b(2) of this enclosure) will be recorded in the SAR. DoD implementation
guidance and assessment procedures are available on the KS. Assessment procedures that are
used that are not in accordance with the KS will be documented fully in the SAR.
(b) Assign Vulnerability Severity Value for Security Controls. Vulnerability severity
[ Pobierz całość w formacie PDF ]