Guide to the Common Body of Knowledge to Produce, Acquire, and Sustain Secure Software


Introduction 1.1Purpose and Scope



Download 1.28 Mb.
Page3/55
Date conversion09.01.2018
Size1.28 Mb.
TypeGuide
1   2   3   4   5   6   7   8   9   ...   55

1.Introduction

1.1Purpose and Scope


The history of computer security goes back at least into the 1960s, and a substantial amount of important work still relevant today was done in the 1970s and early 1980s. Luckily, a project at the University of California Davis collected many of these seminal works and placed on the Internet [Seminal Papers]. Certainly, serious educators, researchers, and others desiring in-depth expertise need to be acquainted with these works.1

For persons with knowledge of software but not security, this document introduces them to the surface of the secure software engineering discipline and points to references for further knowledge. It supplies the background they need to meaningfully recognize the topic a reference covers and which references might be of interest. Given this, while a guide and not a textbook, this document’s content can function as a high-level introduction, and some may choose to use it that way. However, in its primary role, this high-level description and context combines with the numerous references to serve as a guide for educators and trainers as well as others to the software-specific security knowledge relevant to their work (no job requires it all).

The primary audiences for this guide are educators and trainers who can use this guide to help identify both appropriate curricular content and references that detail it. Other audiences include evaluators and testers, acquisition personnel, program managers, and standards developers for whom it can help provide a better appreciation of the breadth of subject matter and issues involved. In addition, studious practitioners could use it to obtain overviews or to guide their learning. In turn, this document’s evolution can benefit from obtaining feedback from users and experts on how it might best be improved or supplemented to become more useful.

This guide concentrates on the additional knowledge associated with producing and acquiring secure software. It mentions only in passing physical, operational, communication, hardware, and personnel security. These are important topics in cyber security but are outside the scope of this guide. Concentrating on software still covers the bulk of the security vulnerabilities being exploited today, although anecdotal evidence indicates that other factors, including but not limited to lack of user awareness and training (social engineering, malicious code attached to emails), lack of secure configuration management, ignorance of the installation of logic bombs, bots, and denial of service agents are also significant contributors to the problem.

This guide cannot, of course, enumerate the knowledge needed in all possible fields in which secure software is needed. Nevertheless, adequate application domain knowledge is required of developers and testers, sustainers, and acquirers for proper evaluation of risks and production of a suitable secure system.

Although detailed product or vendor-specific knowledge is not emphasized in this guide, computer and software security are subjects where often “the devil is in the details.” Thus, projects must often have persons with detailed product, vendor, or technology specific knowledge if adequately secure software is to result from their efforts.


1.2Motivation


The need for a workforce more skilled in the engineering of secure software is clear. The discovery of vulnerabilities2 in software after it has been released can have serious impacts on its producers, in terms of increased costs of testing (both initial and remediation testing), the need to support multiple versions (for other platforms and prior versions still in use), patching, and distribution, as well as in terms of negative impact on the producer’s reputation.3

Applying a single patch can cost large enterprises tens of millions of dollars. As a result, many organizations choose not to apply patches, with the result that their systems retain known vulnerabilities, and become increasingly susceptible to compromise. Increasingly, these compromises include the loss of confidential data processed by the system, subjecting individuals to identity theft and causing firms to suffer significant losses from fraud. Changes in laws and regulations, such as California SB 1386 requiring California citizens whose individual data is compromised to be notified,4 make such data losses public knowledge. Such publicity has caused damage to the reputations of even established firms, with resulting loss of business,5 and has also prompted a number of other states to enact similar data freez and notification laws. A current listing of all states that have such laws in place can be found at http://www.pirg.org/consumer/credit/statelaws.htm.

In addition to the actual costs for producers and users generated by security problems in software, both suffer opportunity costs because valuable resources could be producing added value rather than doing rework and patching.

The problem is not only the result of attempted attacks and insertion of malicious software from both inside and outside organizations but also other issues as well. Many security incidents can be traced back to vulnerabilities that were caused by inadequacies in software requirements, or defects in software design, coding, or deployment configuration. The combination of attacks with defects result in computer and software security problems that are frequent, widespread, and often serious. As cyber security is an imperative concern for Department of Homeland Security (DHS) and Department of Defense (DoD), initially the choice was made to concentrate their Software Assurance efforts on security and to develop this guide.

Although their joint efforts are recent, the DoD and the DHS Software Assurance initiatives and efforts have encompassed software security, software safety6, and several related disciplines. Currently, these efforts are concentrating on achieving and assuring security properties. The Software Assurance Workforce Education and Training Working Group, composed of government, industry, and academic members produced this document.

One of the Working Group’s objectives is to identify and provide references, education, and training that will give software practioners the information they need to develop, sustain,7 and acquire software that is secure—information beyond what they need to know in order produce and assure software for which security is not a concern.

The intended beneficiaries of the information in this guide are expected to span a number of roles. No single software practioner would be expected to know, or even need to know, all of the information the guide contains. However, there are some subsets of the information that should be known by all practioners (e.g., the contents of the first four sections). This guide is designed so that after reading the first four sections readers can then go to the sections of their choice.

While the public prominence of security problems in software is a recent development, security issues related to software have long been studied, and, while open questions remain, considerable bodies of relevant research and practice exist.





1   2   3   4   5   6   7   8   9   ...   55


The database is protected by copyright ©hestories.info 2017
send message

    Main page