Jeffrey A. Ingalsbe

A Comparison of the Software Assurance Common Body of Knowledge to Common Curricular Standards

This paper summarizes the relationship between the specifications of the software assurance common body of knowledge (CBK) and the curricula of software engineering, computer science, and information systems. It identifies where various CBK elements fit within each curriculum and it provides recommendations for additional study based on those findings.

Ensuring Cost Efficient and Secure Software through Student Case Studies in Risk and Requirements Prioritization

This paper presents a discussion of educational case studies used in security requirements assessment and requirements prioritization. Related to this, it introduces risk understanding as an added dimension to the requirements prioritization process. It should be self-evident that the final product should incorporate the requirements with the greatest value. Nevertheless, in a time when security is a preeminent concern it should also be clear that risk elements should also be considered. As such, activities to reconcile risk with value are always essential. However, since risk and value considerations are different, and sometimes opposed to each other, this paper presents a new process that will help decision makers reconcile these two factors within a single approach. This new process may also be incorporated into security requirements education and prioritization.

An Immersion Program to Help Students Understand the Impact of Cross Cultural Differences in Software Engineering Work

Globalization and the attendant demands on multicultural teams have placed new emphasis on ensuring that software engineering students understand the real impacts of social and cultural differences on software engineering work. Cultural differences have specific impacts because our own values are innate. This blind spot can be an extreme hazard when it comes to delivering software that functions properly, is on time and on budget.This paper will present the details of an educational program designed to sensitize software engineers to cultural differences by cultural immersion. It will explain how the program addressed four areas of software engineering work that are susceptible to cross cultural influences, 1) process primitives, 2) abstract representation, 3) oversight and control and 4) optimization.

Teaching Security Requirements Engineering Using SQUARE

This paper details the validation of a comprehensive teaching model for security requirements engineering which ensures that security is built into the software from its inception. It centers on the employment of the SQUARE method for secure software requirements engineering, which was developed at Carnegie Mellon University. The effectiveness of the SQUARE method, its learning system and the initial results of using it in student case studies and in a practical, higher education classroom application are reported.

Defining the Discipline of Secure Software Assurance: Initial Findings from the National Software Assurance Repository

Defect free software is a critical national priority. Yet, we still do not fully understand the shape of the field that underlies the process of producing, sustaining and acquiring secure software. Specifically, there is no common agreement on the knowledge requirements for the field, nor is there even full agreement about the activities that legitimately comprise the process itself. Recognizing this, the Department of Defense, through the National Security Agency, has begun a three-year study to characterize the form and contents of the discipline of software assurance. This type of rigorous study is a necessary first step in formulating an academic study of the field. It is also a pre-requisite to formulating the practical steps necessary to achieve a secure software base. The first phase of the project, which has just been completed, created a database containing the known empirical, theoretical, critical/analytic and methodological knowledge elements of the field. This report utilizes that database to characterize the current state of secure software assurance work and suggest future directions.

A Study of the Impact on Students Understanding Cross Cultural Differences in Software Engineering Work

This is a follow-up to our previous study that presented the details of a program to sensitize students to cultural differences by cultural immersion. In this paper, we studied the impact on the student’s participation in the program with respect to culture and their perspectives on diversity and global business practices in the cross-cultural world of software engineering.

Integrating Secure Software Assurance Content with SE2004 Recommendations

This study identifies the places where software assurance knowledge best fits with the elements of a standard software engineering curriculum. This is useful because there is currently no common understanding of the places in a traditional software engineering curriculum where software assurance should be taught. It would appear that the recommendations of the DHS CBK can be justified as a basis for teaching software engineering concepts for developing secure and assured software.

A Common Sense Way to Make the Business Case for Software Assurance

This article demonstrates how a true cost/benefit for secure software can be derived using three generic practice areas: (1) threat/risk understanding, (2) implementation of security requirements, and (3) operational security testing. Having an accurate cost for these aspects of the software assurance process would allow decision makers to make intelligent decisions about the level of investment they wish to make. WHY WE NEED TO DISTINGUISH SOFTWARE DEVELOPMENT FROM SOFTWARE ASSURANCE The aim of this article is to demonstrate how a common valuation model can be used to make a dollars and cents business case for software assurance. However, in order to do that, it is first necessary to talk about why the elements of software assurance cost have to be differentiated from those of traditional software development. A precise delineation of the cost elements of secure software assurance is required because the total cost of anything is the sum of the costs of its parts. And unfortunately, there is no commonly agreed-on line of demarcation between the activities that constitute software assurance and those associated with producing a correct product. It should be apparent that the cost of producing the product should be different from the cost required to make sure that the product is secure. Yet when it comes time to assign the actual cost associated with each process, the distinction between product quality assurance and product security gets lost. Profit margins drive most business decisions. That is why it is so dangerous to over-inflate the price of secure software. Price inflation happens because businesses tend to confuse the costs required to ensure against exploitation with the much greater costs of producing a correct product. The fact that defects are a given in software does not change the ethical obligation of the maker to produce Antonio Drommi

Supporting the building and analysis of an infrastructure portfolio using UML deployment diagrams

Rational, objective analysis of an infrastructure portfolio requires that the portfolio be represented in a consistent and understandable way. For an organization whose portfolio includes legacy systems, systems under development, systems on fundamentally different and incongruous platforms, and systems with little or no documentation, the task is daunting. This paper describes work currently being undertaken to represent the IT portfolio of Ford Motor Company from an infrastructure perspective using UML deployment diagrams. The objective of the work is to support the analysis of the portfolio and its subsequent alignment with key IT strategies. To accomplish this, the UML deployment diagram was extended and a template created. This paper discusses the extensions, the template, and its ongoing deployment to the organization. Tool considerations and future work are discussed as well