C. Warren Axelrod

Software Assurance (SwA) and the Department of Defense (DoD)

On December 16, 2013 the Office of the Assistant Secretary of Defense for Research and Engineering (ASD(R&E)) issued a Request for Information (RFI) with the title “Software Assurance,” which can be found via on the FedBizOpps website at: https://www.fbo.gov/index?s=opportunity&mode=form&id=3c867a45671f0cde56fca2bf81bdaf44&tab=documents&tabmode=list

There are many interesting aspects to the ASD(R&E) RFI, particularly with respect to something of a recognition that there is “… a current and persistent lack of a consistent approach by the U.S. defense enterprise  (including government, industry and other partners) for the certification of Software Assurance (SwA) tools, testing and methodologies …” Furthermore, the DoD is seeking “…to address vulnerabilities and weaknesses to cyber threats to the software that operates all manner of DoD systems, including both routine applications and critical kinetic systems requiring zero or near-zero fault tolerance.”

It is ironic that many of the above issues might well have been avoided if the DoD had succeeded in its attempt to replace hundreds of programming languages with a single language, called Ada, which was developed from 1977 to 1983. Believe it or not, Ada is still in use 30 years later in various weapons and avionics systems and Ada 2012 was released in December 2012. For more details, see  http://en.wikipedia.org/wiki/Ada_(programming_language)  Be that as it may, we are today saddled with inherently less secure systems written in the likes of C++ and Java. As a result, systems cannot be trusted to the same level as with Ada and so we see the concerns raised in the RFI.

The problem has been made worse by the integration of software from many different sources, including open sources, where the end-user organization has little or no control over the security, integrity and resiliency of the combined systems of systems.

As with many other situations in IT, it is “pay me now or pay me later.” While it might have been considerably cheaper  to create systems in more flexible programming languages (or not), we are saddled with having to build huge software assurance mechanisms and infrastructures in order to convince ourselves that the assured systems meet necessary security and safety standards. However, in many cases, such standards do not even exist in forms that can be readily and unequivocally applied.

While I am not advocating the conversion to, and universal use of Ada, I believe that there are lessons to be learned from history. Perhaps we can have popular languages upgraded with some of the attributes of more trustworthy languages. The failure to do so will only result in the goal of sufficiently assuring software systems moving further and further into the distance.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*