I originally published this article on Medium in February of 2022, when the DoD Software Modernization Strategy was originally released. That said, the DoD just released their Implementation Plan for the Software Modernization Strategy, so I felt it make sense to re-publish this coverage of the strategy, before covering the Implementation Plan, which I will do soon!

Original Article below.

—

The Department of Defense (DoD) has been on a roll lately in terms of releasing relevant memos, playbooks, strategies and more. From the Open Source Software (OSS) Memo, DevSecOps Guides, Playbooks & Reference Designs, Continuous Authority to Operate (cATO) memo to the DoD Software Modernization Strategy. Each of these documents is connected, sewing a tapestry of guidance for a community in desperate need to keep technological pace with adversaries and maintain national security for its citizens.

The push for software innovation in DoD isn’t new, tracing to several studies and efforts, such as the Software Acquisition and Practices (SWAP) Study, GAO Reports and much more. The DoD has a well known problem with software development and acquisition. This has implications for not only military conflict but humanitarian operations and broader national security. It is worth noting that many of these problems aren’t constrained to just the DoD either and also impact the Federal civilian agencies as well.

The strategy opens with discussing why the DoD Software Modernization is relevant for delivering a more lethal force than our adversaries. It also empowers the DoD CIO, Under Secretary of Defense of Acquisition and Sustainment and the Under Secretary of Defense for Research and Engineering to lead its implementation.

To help level set the criticality of impact of capable software delivery the strategy uses several examples. Ranging from five years and three years into the future as well as today. These examples range from humanitarian examples to military and national security ones. It’s evident through the examples used that technology and software delivery are key to the DoD’s competitive advantage and that the DoD must make the ability to rapidly deliver functional secure software and capabilities part of who they are as an organization. It’s also worth noting that Cloud is emphasized throughout the examples provided and it even mentions that the DoD Software Modernization Strategy replaces the DoD Cloud Strategy.

The DoD Software Modernization Strategy document covers the following areas: Software Modernization Vision, Unifying Principles, Software Modernization Framework, Goals and Objectives and Unified Implementation. We will take a look at each of them below.

Vision

The DoD Software Modernization Strategy has a very simple yet powerful vision statement. “Deliver Resilient Software Capability at the Speed of Relevance”.

The vision is emphasized by the reality that the modern battlefield includes digital systems with the weapons and targets being information and data and software acting as the conduit. It’s made clear that while software offers limitless promise and opportunities it is also full of perils and opportunities for misuse and abuse. It’s made clear that for the DoD and the U.S. to compete on the future battlefield it must be able to empower warfighters and capabilities through technologies and software.

There’s an emphasis on not just software delivery but resilient software delivery, able to withstand and recover from potential incidents. This sort of language is reminiscent of NIST’s 800–160 Vol. 2 Rev. 1 “Developer Cyber Resilient Systems”. NIST’s guidance for Cyber-resilient systems focuses on the goals of anticipate, withstand, recover and adapt, and are something the DoD must embrace for it’s digitally enabled systems and software if it hopes to achieve it’s vision.

Unifying Principles

The Unifying Principles in the DoD Software Modernization Strategy revolve around existing strategies and themes, such as fast secure software delivery, leaning in to cloud modernization and capabilities, integration with the broader enterprise, not leaving the workforce behind and the realize that software modernization is more than just code. These collection of principles take advantage of existing efforts such as the continued push for enterprise-wide shared services and platforms and cloud adoption and maturity while also realizing that technology is but a piece of the overall modernization effort. The workforce can’t be left behind and the strategy can’t be executed without changes to existing policies and processes as well.

Software Modernization Framework

Moving on from the Unifying Principles, the Software Modernization Framework acknowledges that there are many ways to obtain software and that software delivery is NOT a one and done activity.

The Software Modernization Framework focuses on what it calls Technical Enablers, Tech Force Multipliers, Process Transformation and Outcomes for the Warfighter, as depicted below.

Technical Enablers: In order to achieve DoD-wide Software Modernization the DoD realizes that modern and emerging technologies are absolutely critical. This includes things such as a DoD Enterprise-wide Cloud Environment, Design Patterns, DevSecOps/Tooling and Enterprise Services. Sticking with the theme of the recent shift to the Joint Warfighting Cloud Capability (JWCC), there’s an emphasis on multi-vendor multi-cloud environments and the adoption of higher levels of Cloud delivery models such as Platform-as-a-Service and Software-as-a-Service, which have largely been ignored by many DoD programs, which approach Cloud as just another data center and often don’t push into managed PaaS or SaaS delivery models, despite their tremendous benefits.

Hopefully this emphasis squashes some of the “vendor lock” hype and FUD and makes it clear that all of cloud, not just IaaS, is key to DoD enterprise-wide software modernization. Leaning in to PaaS and SaaS services can help facilitate many of the key criteria called out in the cATO memo referenced earlier, such as near real-time compliance visibility, dashboards and reporting, so there is a clear synergy here, given cATO is also key for facilitating secure continuous delivery of software in a regulated environment beholden to the Risk Management Framework (RMF). It also is very important to understand the concept of Security Control Inheritance, and how the Shared Responsibility Model (SRM) allows Mission/System Owners to inherit security controls from Cloud Service Providers (CSP)s and Managed Service Provider (MSP)’s (including platforms). This approach tremendously cuts down on the compliance burden left to Mission/System Owners and minimizes the number of Security Controls they must meet. At scale, this impact can be very powerful, especially across many development teams and helps stress the important role that Software Factories and Platforms play.

It’s worth noting that while the modernization strategy emphasizes how important environments, empowered by Cloud technologies, are to software modernization, it still leaves problems that many DoD Mission/System Owners wrestle with. These are issues such as severe lag times to access innovative commercial cloud services due to cumbersome compliance processes such as FedRAMP and the DoD Security Requirements Guide (SRG) and its associated Impact Levels as well as bespoke “Cloud Broker” models implemented by some of the service branches and program offices.

Design Patterns: One of the more promising aspects of the Software Modernization Framework is the acknowledgement of Design Patters. These include things such as pre-hardened Infrastructure-as-Code (IaC) templates which can be used to expedite getting Mission/System Owner operating environments quickly stood up in the cloud with security and compliance requirements baked-in. For a look at some promising efforts on this front, be sure to see the DISA Hosting and Compute Center’s DoD Cloud Infrastructure-as-Code (IaC) efforts.

DevSecOps/Tooling: No discussion of DoD Software Modernization would be complete without covering DevSecOps and its associated tooling. As mentioned earlier, the DoD has been pursuing the push for DevSecOps for some time now and continues to gain momentum. They’ve also released several Strategies, Guides & Playbooks and Reference Designs to help facilitate this pursuit. The overarching theme here is to shift security left earlier into the Software Development Lifecycle (SDLC) and utilizing changes in process and tooling to delivery secure code at the speed of relevance. This is often done through Continuous Integration/Continuous Delivery (CI/CD) and a Software Factory.

This approach leans heavily on the use of automation and technology along with policy and process changes. Speaking of policy, recall that the recently released cATO Memo requires the use of an approved DoD DevSecOps Ref. Design, so you can see how these pieces of strategy, policy and technology are all interconnected. The currently approved DoD DevSecOps Ref. Designs that have been published include CNCF Kubernetes, Multi-Cluster Kubernetes and AWS Managed Service models.

Enterprise Services: Building on the need to both expedite desired outcomes and lean into existing synergies is the call out of enterprise services. These could be things such as shared security services, such as a Cybersecurity Service Provider (CSSP), Identity Management or even DevSecOps and Software Factory platforms themselves.

Tech Force Multipliers: These sections break down the need to leverage the DoD Science and Technology Strategy to maximize the use of emerging technologies to expedite innovation.

Process Transformation

The DoD Software Modernization Strategy stresses the need to change processes to take advantage of new technology. While this section only received a small portion in the overall DoD Software Modernization Strategy, it can’t be emphasized enough how important this is.

Having worked for nearly 15+ years in the DoD and Federal environment securing systems that utilize or deliver software, the problem is almost never related to technology constraints and almost always associated with people and process challenges.

The DevSecOps Artifacts, OSS Memo and cATO Memo are perfect examples of this. Despite DevSecOps, OSS use and the push for cATO all being relevant for several years in DoD, these artifacts are just now being codified and published, and even then are drawing strong rebuke or critiques from some in the community.

Policy and Process will always lag technology, that’s just a rule of nature. That said, if policy and process don’t continue to innovate iteratively allow with technological innovation, all hopes of modernization and national adversary parity will be hamstrung, if not flat out stifled.

The primary areas focused on for Process Transformation include: Business Operations, Acquisition, Cyber Survivability, Testing and the Workforce.

Starting from the top if the recognition that the DoD’s current business operations doesn’t incentivize sharing, reuse and trust of software capabilities. There’s no shortage of fiefdoms and egos that are also at play here.

The reality that acquisition is a constraint is nothing new and has been cited for quite a while, tracing to the SWAP study previously mentioned among others sources. That said the DoD has been making efforts on this front, such as the Software Acquisition Pathway, which strives to provide a rapid, iterative approach to software development and acquisition.

Note the bottom right: “Software is Never Done”. Noticing a theme here yet? (hint: Security is never done either)

Shifting to the Cyber Survivability and Testing Aspect, it’s explicitly called out that Compliance =/= Security. There’s a distinction that compliance should merely be an outcome of properly implementing cybersecurity practices. Refreshingly, it is also emphasized that the DoD has to get away from the snapshot-in-time approach it traditional takes to compliance. This approach traditionally materializes through performing what is known as Continuous Monitoring (ConMon). However, there’s generally nothing continuous about it, other than it continuous fails to actually account for real-time threats and risks to systems. It usually occurs by annually reviewing 33% of the applicable security control baseline once a year over a 3-year ATO window, to account for reviewing 100% of the controls in the typical 3 year ATO lifecycle. I have four kids, and this would be similar to me checking their room to see if it is clean once a month, when they know ahead of time the inspection will occur. Compliance, and often, security, tend to experience drift and deviation shortly after any manual inspection activities.

It is this reality that leads to the Software Modernization Strategy stressing the need for a shift to compliance automation, near real-time compliance monitoring and even more importantly, accounting for real-time risk monitoring. These are also key concepts in the cATO Memo we’ve continued to reference.

There’s also the explicit need to address supply chain risk, which is where concepts such as SBOM’s, VEX, attestation and more will come in to play. You’ll see an increased push for software asset inventory, implementing best practices from NIST’s 800–161 Rev. 1 “Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations”. Specifically Appendix F, which provides a response to the Cyber EO 14028 and provides guidelines for Enhancing Software Supply Chain Security. Building on the need for modern software security chain practices is the need to implement automated security testing to help facilitate more effective Defense Cyber Operations (DCO). All of these practices will need to be incorporating into standard DoD Cybersecurity activities to achieve Cyber Survivability.

Penetration Testing also gets a nod of significance, noting that it must occur not just during development but during operations as well. Penetration testing was explicitly called out in the Cybersecurity Executive Order (EO), specifically in Section 4. That said, I would be remiss if I didn’t mention that recently the Pentagon’s Director of Operational Test and Evaluation (DOT&E) stated that there is a lack of operationally-realistic testing. This included items such as insufficient time, tooling and unrealistic rules of engagement. If these issues aren’t addressed, then the ROI of Penetration Testing will remain questionable.

Workforce: There’s a blatant acknowledgement that the DoD needs to improve its workforce practices. This ranges from attracting and retaining talent, up-skilling existing talent and re-addressing how the DoD handles careers and workforce synergy. This topic could be an article all of its own, so we will take a wait and see approach if the DoD adopts modern workforce practices in terms of hiring, retention and flexibility, or if it continues to flounder and lacks a workforce to implement its desired strategies.

Outcome: Ultimately the goal of all of these technical enablers and process transformation focuses is getting better capabilities into the hands of those who matter most, DoD warfighters and Mission Owners. If the outcomes aren’t achieved then all of the strategic objectives and focus areas are futile.

Goals and Objectives

We will wrap up our breakdown of the DoD Software Modernization Strategy by looking at the defined goals and objectives. There are 3 high level goals defined, which include: Accelerating the DoD Enterprise Cloud Environment, Establishing a Department-wide Software Factory Ecosystem and lastly Transforming Processes to Enable Resilience and Speed.

Once again it is stressed that the enterprise cloud environment is absolutely key to serving as the foundation for the DoD’s software modernization. This includes cutting across multiple CSP’s, and classification environments, both at the enterprise and tactical edge. To put it lightly, the DoD has a troubled history with Cloud, particularly its long and drawn out JEDI effort, which focused on a single enterprise cloud but never fully materialized and now has led to the Joint Warfighter Cloud Capability (JWCC), which is multi-cloud oriented.

The objectives of accelerating the DoD Enterprise Cloud Environment is multi-faceted. It revolves around four focuses: An Innovative Portfolio of Cloud Contracts, Securing Data in the Cloud, Accelerating Cloud Adoption, and Preparing OCONUS Infrastructure for the Cloud.

As mentioned in the introduction, the DoD has no shortage of drama surrounding its cloud contracts. That said, things finally seem to be trending in a better direction, with the recognition of the need for diverse portfolio of contract vehicles that allow for enterprise wide adoption and access to multiple CSP’s and environments.

Securing data in the cloud consists of through components, which include the appropriate authorization processes coupled with Defensive Cybersecurity Operations (DCO)’s. Anyone who has worked with cloud in DoD is no stranger to the required authorization processes. First you have FedRAMP on the Federal Civilian side, which authorizes Cloud Services Offerings for Federal consumption and then DoD builds upon that with their own Provisional Authority to Operate (P-ATO) process and requirements in the Security Requirements Guide (SRG), with its addition controls (often referred to as FedRAMP+) and unique security requirements for various Impact Levels (IL)’s.

While the DoD Software Modernization Strategy emphasizes this authorization process, it doesn’t make any comments or insight regarding optimizing or improving the currently compliance requirements, which inarguably add tremendous lag time for DoD Mission/System Owners to get access to innovative commercial cloud services. It does mention that the processes must be faster, but doesn’t give any insight on how that will occur, so hopefully that will follow.

On the DCO front, this often materializes in the form of Cybersecurity Service Providers (CSSP)’s, such as DISA and others. While DCO is unquestionably critical to securing DoD data in the cloud, it is not without its challenges. There’s plenty of stories of CSSP’s pushing legacy security tool stacks onto innovative forward leaning Cloud-native systems in the DoD. The DoD is continuing its adoption of technologies like Kubernetes, Containers, Serverless and more. DCO’s need to align with these technologies and focus on outcomes over specific tooling and provide dynamic tech stacks and tools that meet the customers environment, not blanket based approaches that often lead to a mismatch between the customer environment and the DCO’s technologies and methodologies.

Accelerating Cloud Adoption Through Design Patterns focuses on technologies like pre-hardened Infrastructure-as-Code (IaC), which we’ve discussed with efforts such as the DISA IAC. It also touches on pre-hardened containers, and we’ve seen efforts on this front such as the DoD Platform One’s Iron Bank, which aims to try and create a repository of pre-hardened containers and utilize reciprocity to avoid duplicative assessment and security work and offer these out to the enterprise. Despite these efforts there is still widespread mistrust among, and within the services on leveraging these sources, and some would argue justifiably so. Any push for reciprocity in a risk averse environment like DoD will require rigorous documentation and test results to gain the trust of would be adopters, so we should approach it accordingly. Trust but verify requires artifact to verify with. Building on these design patters, there is also opportunities to make improvements on the actual security documentation as front. Programs such as NIST’s Open Security Controls (OSCAL) assessment language allows for the codification of traditional security documentation. This can help usher in better version control, auditing, assessment and automation by making paper based documentation machine readable. The DoD and broader Federal government but embrace this push if it wants to streamline and improve assessment and authorization activities, which will help accelerate Cloud adoption as well, which is ultimately the goal as outlined.

Preparing OCONUS Infrastructure for Cloud is an another critical component of the goal. The value that cloud provides to national security goals and ambitions isn’t limited to the continental U.S. and this goal emphasizes that. In 2021 the DoD released its OCONUS Cloud Strategy, which states it “establishes the vision and goals for enabling a dominant all-domain advantage through cloud innovation at the tactical edge”. So be sure to give it a read here.

Goal 2 focuses on continuing to foster the bolstering Software Factory ecosystem in the DoD. From Platform One, Navy Overmatch Software Armory, Air Force’s SkiCAMP, and Army Software Factory, just to name a few, the DoD’s Software Factory ecosystem continues to strive. These organizations are setting the tone for DoD software innovation and delivering resilient software solutions at the speed of relevance.

This goal has several sub-components, which we will seek to summarize.

First off is DevSecOps through Enterprise Providers. It says “DoD must establish requirements for a reasonable number of enterprise providers to efficiently scale software factories”. The goal here is obvious, to avoid duplication of work, maximize existing investments and lead to some level of standardization and governance. The challenge lies in “reasonable number”. Who determines that number, and what dictates it? If you’ve been in the DoD Software Factory ecosystem, you know there are plenty of egos, fiefdoms and silos. How do you foster a diverse and innovative ecosystem while also avoiding massive duplicative work and spending? Therein lies the challenge.

cATO remains a core component of the DoD Software Modernization Strategy, once again popping up in Goal 2. The document explains how cATO helps shift from a check-the-box approach based on hundreds of compliance controls to an opportunity to bake security in to the SDLC, automate security checks through tooling and facilitate real ConMon as previously discussed. That said, with the diverse ecosystem of Software Factories, the recent cATO memo put the DoD CISO in the position as being the only authority who can approve a cATO. You can see where this is potentially leading to a bottleneck of centralized authority. That said, recent comments by DoD CIO John Sherman on a LinkedIn Post of Paul Puckett’s emphasize that the DoD’s approach to cATO is still evolving, with the goal to eventually decentralize control and empower the various MilDep’s and Programs to have some level of autonomy when it comes to granting cATO’s. Let’s hope that process doesn’t take too long to avoid becoming a bottleneck.

The final three areas of this goal focus on reciprocity (there goes that term again) of tools in an enterprise repository, streamlining control points and compliance and lastly speed innovation to the hands of the warfighter. All three of these items have something in common. Implementing efficiencies in both technologies and processes to expedite outcomes to the most critical stakeholder, the warfighter. Realizing these three goals is key to doing so.

Remember how we previously acknowledged that most barriers to innovation aren’t technology related, but often related to people and importantly, process. This goal helps drive that home recognizing that the DoD is an incredibly complex ecosystem with a myriad of overlapping requirements, policies and laws governing it. This must be improved to enable the speed of delivering resilient software and capabilities to warfighters.

This goal focuses on many of the themes previously mentioned, but with a bit more specificity. Things such as agile acquisition, data as a first class citizen, improving and up-skilling the workforce and incentivizing the use of Enterprise Shared Services.

All of these items will be fundamental to enabling previous goals and aspects of the strategy as previously laid out. One of the best ways to do this in my opinion is to bridge the traditional gap between those who create policy and the entities it’s applied to. We need to bring technologists into the process of policy creation. If the DoD is looking to empower innovation and agility through software and technology, then those creating software and leveraging technology should be key stakeholders in helping craft policy to facilitate those outcomes. All too often policy is written by individuals separated both organizationally from those it governs and the technologies it applies to. Changing this can make policy and process change more effective and help reach the desired outcomes and goals for the warfighter and broader DoD.

Conclusion

I hope you’ve enjoyed this breakdown of the DoD Software Modernization Strategy. As someone who’s spent most of their adult life working in software and cybersecurity around the DoD and Federal government, both in and out of uniform, I’m incredibly passionate about this topic. While I’ve been able to see and contribute to some of the innovations underway, I’ve also experienced firsthand many of the pain points articulated in this DoD Software Modernization Strategy. I’m hopeful that with empathy, grit and the right leadership we can help the DoD and nation achieve the goals as outlined.

One thing is for sure, the future of our nation and its influence, security and autonomy depend on it. As the strategy ends with: