A DOD Hybrid-Risk Management Framework (RMF) Step 3

Connect--But, be very careful

Getting System Developers to get Cyber Right Early…we hope


A challenge facing the Department of Defense (DOD) is the allocation of time and coordination to properly execute Step 3, the Implementation of Security Controls, of the Risk Management Framework (RMF). 

In Step 3, the cybersecurity team is to work with the developers to ensure all security controls identified in Step 2 are applied.  The challenge continues to be Program Managers (PM) are not scheduling adequate time to conduct this during this phase of the RMF process. In the past, under the DoD Information Assurance Certification and Accreditation Process (DIACAP), the process has taken typically 6 months to receive an Authority to Operate (ATO).  More typically, the current allocation of three to four weeks continues to force cybersecurity specialists to conduct insufficient reviews. They are forced based upon the developers unintentional (or intentional) desire to ignore cybersecurity control requirements of NIST 800-53, specifically, to “rush through” the process. The cyber-assessors only have time to conduct cursory document reviews, and not the needed assessments, interviews, and testing of systems to provide a complete picture of the security posture of a target system. 

**At least two (2) months is required here to adequately complete this hybrid “step” of the process** .

While the expectation is that the developer or developers will conduct their own preliminary security scans and fixes to the target software/system, it has unfortunately seldom occurred based upon the author’s years of secure system development experience; it has resulted in an inconsistent implementation of secure software delivery within the government.  This includes numerous and severe vulnerability findings that neither been get corrected nor mitigated prior to delivery to the government.

The “workaround” attempts to compress the schedule and afford adequate time for the cybersecurity validator team and developers will occur during the Functional Qualification Testing (FQT) period.  (See Defense Acquisition University (DAU) for more information or refer to DOD Directive 5000.02, Defense Acquisition.)

Also, see the Defense Acquisition Life Cycle Compliance Baseline.


Having the security controls (Step 2) approved prior to implementation is preferred; however, earlier entry can still occur without impacting the intent of this solution. 

Also, this is an opportune time for security scans to be locally conducted and reviewed.  While the code is at the developer’s site, the cybersecurity team can review onsite scans, identify high impact vulnerabilities (Category I) findings, and assist the developers in better understanding their selection (not the role of the assessors) RMF controls.



What is needed to be effective? 

Assumptions:

  • The code is locked-down and the PM has approved the current stable baseline.
  • The Preliminary Design Review/Critical Design Review (PDR/CDR) is completed and approved.
  • The system is categorized (Step 1), the security controls are selected (Step 2), and the designated Authorizing Official (AO) has approved these Steps.
  • The packet has been initiated in eMASS (for DOD systems).

Hybrid-Step 3 Site Visit Requirements to the developer’s location:

  • Cybersecurity Assessors:
    • Access to vulnerability scans and configuration scans (automated and manual) on Day 1.
    • Non-disclosure Agreements (NDA) to protect parties and Intellectual Property rights, as required.
    • Train and assist the developers in formulating business cases (mitigation strategies) to address how to either correct or mitigate technical security controls. Provide training as requested as part of the visit.
    • Provide the developers with an understanding of vulnerabilities that may be correctable or requiring Risk Acceptance (RA); this provides preliminary information so cybersecurity can be preparing an RA or waiver action.
  • Developers:
    • Be prepared to provide scan results (formalized meeting and presentation) to the Assessors on Day 1.
    • Require developer software engineer representation that can answer questions about technical issues preventing the developer from meeting NIST 800-53 control requirements.

Conclusion

In order for this solution to be effective, it will require government support and approval to include the backing of the respective Contract Officers Representative (COR).

The overall intent is to create a mechanism to conduct preliminary security assessments of software to ensure its compliance with DOD and NIST directives and policies. This will provide a needed preliminary status to formal cybersecurity testing in conjunction or separately with government developmental testing and approval efforts.


In this SECOND EDITION of THE AGILE SECURITY DEVELOPMENT LIFE CYCLE (A/SDLC) we expand and include new information to improve the concept of “Agile Cyber.” We further discuss the need for a Security Traceability Requirements Matrix (SecRTM) and the need to know where all data elements are located throughout your IT environment to include Cloud storage and repository locations. The author continues his focus upon ongoing shortfalls and failures of “Secure System Development.” The author seeks to use his over 25 years in the public and private sector program management and cybersecurity to create a solution. This book provides the first-ever integrated operational-security process to enhance the readers understanding of why systems are so poorly secured. Why we as a nation have missed the mark in cybersecurity? Why nation-states and hackers are successful daily? This book also describes the two major mainstream “agile” NIST frameworks that can be employed, and how to use them effectively under a Risk Management approach. We may be losing “battles, ” but may be its time we truly commit to winning the cyber-war.
%d bloggers like this: