2 keys to enhancing DOD’s new risk framework

In mid-November, the Government Accountability Office and Veterans Affairs Department Inspector General testified before the House Veterans Affairs Committee regarding the deficiencies in the VA’s cybersecurity program. After failing its cyber audit for the 16^th straight year, the VA was called out for not effectively fixing its network vulnerabilities. One of the main concerns included in the report was the over-utilization of systems that were issued a temporary authority to operate (ATO), a formal declaration that a solution has passed the certification and accreditation (C&A) process.

It’s unlikely that the VA is alone in this regard, as a formal C&A process can take upwards of nine to 12 months to complete. With the movement toward integrating continuous monitoring solutions, this has the potential to add time and resource requirements into the process. The Defense Department is facing this challenge now with the transition away from its specialized C&A process – known as the DOD Information Assurance Certification and Accreditation Process (DIACAP) – to a new platform called the DOD Information Assurance Risk Management Framework (DIARMF).

An important component to DIARMF is the incorporation of continuous security scanning capabilities.  Another addition is the timeframe for re-accreditation, which is decreasing from a three-year window to 18 months. How will this impact the overall process?  What will DOD need to do in order to streamline accreditations to meet the new DIARMF guidelines? Here are two recommendations, from a software perspective, that DOD agencies should require from their vendor partners to better address the DIARMF process.

Security development lifecycle

When developing or updating a piece of software, it is critical for vendors to consider the security implications throughout the process. Quite often, this is something that gets “bolted on” at the end of the development cycle, resulting in what can be considered a patch to a potentially larger issue. By incorporating security into every step of the software development process, from design and development to testing and reporting, the potential to have inherent vulnerabilities decreases dramatically. This includes embedding security awareness into the end-to-end lifecycle of the specific software platform, delivering comprehensive protection and integrating mitigation of zero-day threats through secure coding practices.

This defense-in-depth model of software security mitigates risk for the end user, in this case DOD. By integrating threat modeling capabilities and automated testing for security during development, software vendors can assess and manage customer risk from code changes, as well as appropriately time security-related code modifications for minor releases to additionally minimize risk.  This approach also provides enhanced agility to incorporate the DIARMF security requirements without slowing development. 

This is a win-win from both the government and vendor side, as the vendor can get its product to market faster with the DIARMF security requirements entrenched. From the government’s perspective, it receives a solution that its IT leaders know will meet the DIARMF requirements, significantly reducing the cost and time associated with the accreditation process. Ultimately, this approach puts the focus on security into the process as opposed to what has notoriously been a “check-the-box” mentality to security in software development. 

Embedded Security Technical Implementation Guide (STIG)

Talk to any IT administrator or security professional within DOD and the topic of the STIG – technical guidance for securing systems and software – is likely to come up as a pain point. STIGs are long, detailed and manual. Often containing hundreds of pages, adhering to or upgrading software or systems to a particular STIG is a significant time sink for those involved, requiring well-trained engineers who are skilled in both the technical system and the security guidance.

DOD agencies should require their vendor partners to integrate machine-readable code into their software solutions to simplify the process of checking security baselines and to support DOD’s transition to real-time/continuous monitoring, which, as noted, is a component of DIARMF. This embedded STIG would be hardened at the time of system boot to guarantee compliance both off-the-shelf and out-of-the-box. An electronic STIG would replace the current complex STIG process that involves individuals, or more than likely a group of individuals, to manually check – and update – every setting to ensure compliance with the STIG. Automating the process can turn a 9-12 month accreditation process for the DIARMF transition to a matter of minutes, reducing administrative overhead and enabling these individuals to focus on other activities in support of the DOD mission.

Officially put into place in March of 2014 by then-DOD CIO Teri Takai, DIARMF is here for at least another 5-10 years, unless it is reissued or cancelled. DOD needs to ensure its software vendor partners, in particular, are prepared for the new requirements and new timelines. This preparation should start in the development stage. By incorporating a security development lifecycle approach and integrating a machine-readable STIG component, software vendors can significantly streamline the process, helping to enhance DOD’s risk framework.