The Department of Homeland Security Build Security In Portal

The Department of Homeland Security Build Security In Portal^[4]

^[4] Known in government acronym speak as the DHS BSI PRTL.

The U.S. Department of Homeland Security is developing a software security portal (along with the Carnegie Mellon Software Engineering Institute and Cigital). This portal aims to provide a common, accessible, well-organized set of information for practitioners wishing to practice software security. The portal effort is expressly aimed at the problem of encapsulating, expanding, and spreading software security knowledge.

Knowledge Catalog: Principle Item: Principle of Least Privilege

Two Example Catalog Entries: A Principle and a Rule

Description:

Every program and every user of the system should operate using the least set of privileges necessary to complete the job. Primarily, this principle limits the damage that can result from an accident or error. It also reduces the number of potential interactions among privileged programs to the minimum for correct operation so that unintentional, unwanted, or improper uses of privilege are less likely to occur. Thus, if a question arises related to misuse of a privilege, the number of programs that must be audited is minimized. Put another way, if a mechanism can provide "firewalls," the principle of least privilege provides a rationale for where to install the firewalls. The military security rule of "need-to-know" is an example of this principle.

Concrete example:

A good software specific example is a mail server which accepts mail from the Internet, and copies the messages into a spool directory; a local server will complete delivery. It needs rights to access the appropriate network port, to create files in the spool directory, and to alter those files (so it can copy the message into the file, rewrite the delivery address if needed, and add the appropriate "Received" lines). It should surrender the right to access the file as soon as it has completed writing the file into the spool directory, because it does not need to access that file again. The server should not be able to access any user's files, or any files other than its own configuration files.

The excerpts above are from the book Computer Security: Art and Science by Matt Bishop [Bishop 2003] and are reprinted with permission from Addison-Wesley Professional.

References: [Bishop 2003; Saltzer and Schroeder 1975; Viega and McGraw 2001]

Knowledge Catalog: Rule

Item: Use of creat()

Context: C/C++

Attack Category: TOCTOUtime of checktime of use

Description:

The creat(char *pathname,mode_t theMode) function either creates a new file or prepares to rewrite using pathname as the filename. The call creat(theName,theMode) is equivalent to

open(theName,O_WRONLY | O_CREAT | O_TRUNC, theMode)

If the file exists, the length is truncated to zero and the mode and owner are unchanged.

This function is a problem because it is possible to unintentionally delete a file or enter a potentially unstable race condition.

creat() is vulnerable to TOCTOU attacks. Using automated scanning tools, the existence of a call to this function should be flagged regardless of whether a "check" function precedes it.

Method of Attack:

The creat() call is a "use" category call that when preceded by a "check" category call can indicate a TOCTOU vulnerability.

Solution:

Consider using a safer set of steps for opening and creating files as outlined in Building Secure Software [Viega and McGraw 2001, p. 220]. If this call must be used, create a directory only accessible by the UID of the running program, and only manipulate files in that directory.

Signature: Presence of the creat() function.

Code Example:

char filename[] = "rightFile.txt"; strcpy(filename,"wrongfile.txt"); creat(filename,theMode);

In this case, the contents of the file passed into the creat() function are destroyed.If the results of the function call are used before completion, then the results can also be unstable.

References: [Viega and McGraw 2001] and Microsoft Developer Network Library (MSDN)

Like this book, the Build Security In (BSI) Software Assurance Initiative seeks to alter the way that software is developed by building security in from the start so that it's less vulnerable to attack. BSI is a project of the Strategic Initiatives Branch of the Department of Homeland Security's National Cyber Security Division (NCSD). NCSD sponsors development and collection of software assurance and software security information that will help software developers and architects create secure systems.

As part of the initiative, a BSI content catalog will be available on the US-CERT Web site <http://buildsecurityin.us-cert.gov/portal/>. This portal is intended for software developers and software development organizations who want information and practical guidance on how to produce secure and reliable software. The catalog is based on the principle that software security is fundamentally a software engineering problem that we must address systematically throughout the SDLC. The catalog contains and links to a broad range of information about best practices, tools, and knowledge.

Figure 11-3 identifies aspects of software assurance currently covered in the catalog. Material is divided into three major categories: best practices, tools, and foundational knowledge. This is an alternative way of organizing software security content with reference to artifacts.

Figure 11-3. The organizing concept for the BSI portal. The alignment of this view shows not only best practices (as Figure 11-2 does) but also knowledge and tools.

The categorization is the result of merging an earlier collaboration framework with ideas presented in the lifecycle touchpoints diagram that serves as the skeleton of this book. The National Cyber Security Taskforce's report also identified additional practices to produce secure softwaresee <http://www.cyberpartnership.org/init-soft.html>. The BSI portal will supplement the taskforce's practices with process models and references to appropriate tools, measurement, and other resources.

Although the team creating the portal won't achieve complete content coverage immediately, DHS has launched the portal with some content in each area shown in Figure 11-3. The BSI team will use feedback received on this content (as well as input from industry) to prioritize further work on the catalog.

The portal includes several types of information, categorized for efficient search and utility as follows.

Best practices: A significant portion of the BSI effort is devoted to best practices that can provide the biggest return considering the current best thinking, available technology, and industry practice. This list will grow as more resources become available, more practices are proven, changes occur in the industry environment, and technology progresses. This book covers a number of critical best practices in some detail.

Knowledge: Software defects with security ramificationsincluding implementation bugs such as buffer overflows and design flaws such as inconsistent error handlingpromise to be with us for years. Recurring patterns of software defects leading to vulnerabilities have been identified by long-time software security practitioners, and the BSI team is documenting detailed instructions on how to produce software without these defects. This work shows up in Figure 11-3 as "Guidelines" and "Coding rules."

The BSI team has also identified principles that provide high-level direction for avoiding security problems in design, such as the principle of least privilege and the principle of compartmentalization. The BSI team is collaborating with the National Institute of Standards and Technology (NIST), the International Organization for Standardization (ISO), and the Institute of Electrical and Electronics Engineers (IEEE) on standards activities focused on developing safe and secure subsets of languages and software assurance style guides.

Tools: The BSI portal includes information about which tools developers and security analysts can use to detect and/or remove common vulnerabilities. Of particular interest are static analysis tools that help developers look for common security-critical problems in source code. The best current commercial tools support languages like Java, CLR, C++, C, and PHP.

Business case: Even with extensive technical content, a business case is required to convince industry to adopt secure software development best practices and educate consumers about the need for software assurance. Therefore, each documented best practice addresses the business case for use of that practice. In addition, we've included an overall business case framework.

Dynamic navigation: The extent to which users will find the content accessible as well as useful will determine how this portal will impact real-world development practices and, thus, overall systems security. The BSI team is making the content approachable in several different ways. For example, a software engineer might use the catalog to determine applicable security guidelines, an architect might use security principles to determine how to design an n-tier application in a secure fashion, and a development team leader might use the information to justify software assurance techniques to management by building a business case. Because the repository will be structured and designed to evolve as well as support usage by a variety of user types, it includes a dynamic navigation interface.

Once practical guidance and reference materials are available for the day-to-day work most development organizations do, the BSI team plans to identify and organize content for practical guidance and reference materials for enterprise-level security concerns.

Although the portal is currently in a nascent stage, the BSI team welcomes feedback on this effort. Information on providing feedback can be found on the portal itself; community involvement and use is crucial to its success.