DETROIT – Current software engineering practices inadvertently leave software and systems susceptible to attacks. As evidence, the DHS’s Common Weakness Enumeration (CWE) lists 797 explicit defects and the list is growing at a constant rate. These defects cost the average U.S. Company $22 million dollars a year to fix.

Moreover, it isn?t like recommendations for correct practice don’t exist. The Department of Homeland Security has produced a 387 page document that specifies a comprehensive set of practices to assure the secure development, sustainment and acquisition of code. These range from heavyweight design methods to model contract language for vendors.

The problem is that none of these recommendations have made their way into common practice. Disseminating them is the aim of these two projects. Together they are beginning the slow process of moving higher education toward more comprehensive understanding of what is needed to produce secure code.

Software Defects and the National Strategy

Since 9/11, it has been a matter of national interest to do something about the problem of insecure code. Yet “commonly used software engineering practices permit dangerous defects, which let attackers compromise millions of computers every year.” This happens because “commercial software engineering lacks the rigorous controls needed to [ensure defect free] products at acceptable cost.”

As a result, the creation of a National Cyberspace Awareness and Training Program was among the three highest priorities in “The National Strategy to Secure Cyberspace” developed in 2002. The aim of that program was to “improve cybersecurity knowledge, and understanding of the issues” and to produce a “sufficient number of adequately trained … personnel to create and manage secure systems.” The cornerstone of the initiative was the mandate to ensure ?adequate training and education to support cybersecurity needs?. The aim was to guarantee that software assurance practices would be integrated into the day-to-day activities of the overall workforce.

Getting the Message Out

The traditional means of disseminating knowledge into society is through formally constituted education, training and awareness programs. The problem is that there is no single point of reference to ?guide the development and integration of education and training content relevant to software assurance?. The National Strategy recognizes that fact in Action Recommendation3/6 [1], which stated that “research and development efforts [should be conducted] in the general area of secure software assurance in order to … coordinate the development and dissemination of best practices for cybersecurity.” The obvious question eight years later is, “How close are we to achieving that goal?”

The problem with dissemination is that software assurance knowledge is crosscutting rather than disciplinary. In essence, the knowledge base for software assurance is located in a range of traditional studies. That includes such dissimilar areas as “software engineering, systems engineering, information systems security engineering, safety, security, testing, information assurance, law and project management.” As a result, secure software assurance content might appear in many different places and be taught in many different ways in conventional education settings.

It is clearly unacceptable to approach the teaching and learning process in such a disjointed way. Therefore, the way educators disseminate the secure software assurance knowledge has to be coordinated. In order to coordinate that learning process, a formal effort has to be made to integrate ?software assurance content … into the body of knowledge of each contributing discipline?. There are two practical barriers to achieving that outcome. First, it is not clear what specific knowledge and skills should be taught in each area. Second, there are no validated methods for delivering that knowledge once it has been identified.

Ensuring Learning Content for the Field of Software Assurance

Logically, the first step in integrating new knowledge into conventional learning environments is to identify, relate and catalogue what is presently out there. That is the goal of a three-year project funded by the Department of Defense (DoD) and conducted at the University of Detroit Mercy. This project has attempted to identify and document any knowledge, from any source, that could be related to the assurance of software.

That knowledge came from all of the usual computing disciplines, such as computer science, software engineering and information systems. Additionally, besides strictly technical areas, the project also incorporated the conventional areas of information security, as well as relevant knowledge from the behavioral and social sciences. The knowledge was obtained came from all accessible public and private sector sources.

The resulting knowledge base encompasses and relates all commonly accepted practices, principles, methodologies and tools for software assurance. It is managed by an automated online knowledge management system. The mind map that underlies the knowledge management system is roughly based on the Department of Homeland Security’s “Software Assurance: A Guide to the Common Body of Knowledge to Produce, Sustain and Acquire Secure Software.” However, to ensure the validity of the CBK framework, the mind map was fine tuned and validated by means of a classic Delphi study. That study was conducted using a panel of 11 nationally known experts in secure software assurance.

The knowledge base contains as many lifecycle methodologies and tools for assuring software as could be identified. It also itemizes all related supporting principles and concepts that are aimed at increasing the assurance and security of internally developed and sustained software. That also includes products and services purchased from outside vendors. The knowledge base is evolutionary and inclusive. Thus, as the literature of the field expands, or new sources are identified, that material will be catalogued and added to the current knowledge base.

Developing Pedagogy

Nevertheless, the actual purpose of the University of Detroit Mercy project was not simply to gather knowledge. The goal was to ensure the teaching of secure software topics in all appropriate education, training and awareness settings. In support of that goal, the project has packaged the contents of its knowledge base into discrete learning modules. These modules are designed to facilitate the efficient transfer of software assurance knowledge into all relevant teaching and learning settings. As a result, the modules can be incorporated into a wide range of teaching and learning environments. They are appropriate for traditional graduate and undergraduate, community college and even high school education, as well as training and awareness applications.

The modules are intended to be discrete, standalone learning artifacts capable of conveying all of the requisite know-how for a given topic. At a minimum, each module can be delivered in a conventional classroom. However, the modules embody supporting material that also allows them to be delivered in a range of asynchronous and web-enabled learning environments. That flexibility facilitates the efficient transfer of new workforce skills and practices to all types of education, training and awareness settings.

Each module conveys a logical element of software assurance practice. The entire collection of these modules is mapped to the body of knowledge contained in the knowledge base. Since that knowledge base is structured on the most commonly accepted model for secure software assurance practice, the DHS Common Body of Knowledge [7], this mapping provides precise guidance about the places where the newly developed instructional content fits within the commonly accepted understa