The NDAA Pushes Forward on Cyber Metrics

Cybersecurity is an art, not a science—or so it seems today. I have been interested for some time in how to change that. At least to me, the key seems to be the development of a system of cybersecurity metrics that are transparent, auditable, scalable and generally accepted. Yet at times, it seems like incentivizing the creation of a cyber metrics system is impossible, akin to trying to move the entire Earth.

Archimedes is reported to have said: “Give me a lever long enough and a fulcrum on which to place it, and I shall move the world.” In the world of cybersecurity, Congress may just have given the idea of cyber metrics a long lever—the procurement process—with which to move the cyber metrics field.

The 2020 National Defense Authorization Act (NDAA) is chock full of interesting tidbits. One that caught my eye is Section 800, which bears the daunting title “Authority for Continuous Integration and Delivery of Software Applications and Upgrades to Embedded Systems.” Despite the mouthful, the genesis of the provision is relatively easy to understand: For more years than most can remember, the Department of Defense has been remarkably ineffective at procuring software in a timely manner. Upgrades that take days or weeks in the private sector seem to linger for months or years at the Pentagon. As the conferees put it in the report accompanying the bill:

The conferees emphasize that the ability to deliver meaningful capability for operational use within one year is foundational to the establishment of this authority and associated procedures. The conferees remind the Department that delivery of increments of useful software capability no less frequently than every six months is not only a best practice for software-intensive systems but it has also been a standing government-wide requirement for years. Overcoming the Department’s institutional and cultural resistance to delivering in a year or less requires ruthless prioritization of features, which hinges on more effective cooperation among stakeholders.

Though cause and effect are always hard to demonstrate, the systematic failure of the Defense Department to improve software procurement is potentially implicated in problems like the suspected vulnerabilities in the F-35’s cyber systems. Hence, Section 800, which authorizes the department to create procurement pathways in which software can be purchased in less than a year. If implemented effectively, the change would be dramatic.

Which brings us to cybersecurity metrics. Congress, in its wisdom, has set forth guidelines for the Defense Department as to the components of a successful rapid procurement pathway. Many guidelines reflect concepts of software development borrowed from the field of DevOps (e.g., close coordination with the end user and early identification of software gaps, as well as evolutionary development processes). One, in particular, stands out. Section 800(d)(9) provides that the rapid procurement pathway must incorporate requirements relating to:

assurances that cybersecurity metrics of the software to be acquired or developed, such as metrics relating to the density of vulnerabilities within the code of such software, the time from vulnerability identification to patch availability, the existence of common weaknesses within such code, and other cybersecurity metrics based on widely-recognized standards and industry best practices, are generated and made available to the Department of Defense and the congressional defense committees.

This could be transformative. The allure of a rapid procurement process is great—most software developers will prefer that pathway to one that takes years longer to complete. And now Congress has made access to that pathway contingent on the availability of some high-level cybersecurity metrics.

Until now, the discussion around the best and most readily implementable forms of cyber metrics has been mostly academic. But this issue has now taken on far greater urgency. The Defense Department has, under the NDAA, just a year to set up the rapid procurement pathway. That means that within a year, the department must identify more concretely exactly which metrics it will use to ensure that the software it procures is less vulnerable. Through the procurement process, Congress is about to alter how software is written and evaluated—and that’s a real change for the better.