“I’m an enthusiastic supporter of the CERT Secure Coding Initiative. Programmers have lots of sources of advice on correctness, clarity, maintainability, performance, and even safety. Advice on how specific language features affect security has been missing. The CERT® C Secure Coding Standard fills this need.”
–Randy Meyers, Chairman of ANSI C
“For years we have relied upon the CERT/CC to publish advisories documenting an endless stream of security problems. Now CERT has embodied the advice of leading technical experts to give programmers and managers the practical guidance needed to avoid those problems in new applications and to help secure legacy systems. Well done!”
–Dr. Thomas Plum, founder of Plum Hall, Inc.
“Connectivity has sharply increased the need for secure, hacker-safe applications. By combining this CERT standard with other safety guidelines, customers gain all-round protection and approach the goal of zero-defect software.”
–Chris Tapp, Field Applications Engineer, LDRA Ltd.
“I’ve found this standard to be an indispensable collection of expert information on exactly how modern software systems fail in practice. It is the perfect place to start for establishing internal secure coding guidelines. You won’t find this information elsewhere, and, when it comes to software security, what you don’t know is often exactly what hurts you.”
–John McDonald, coauthor of The Art of Software Security Assessment
Software security has major implications for the operations and assets of organizations, as well as for the welfare of individuals. To create secure software, developers must know where the dangers lie. Secure programming in C can be more difficult than even many experienced programmers believe.
This book is an essential desktop reference documenting the first official release of The CERT® C Secure Coding Standard . The standard itemizes those coding errors that are the root causes of software vulnerabilities in C and prioritizes them by severity, likelihood of exploitation, and remediation costs. Each guideline provides examples of insecure code as well as secure, alternative implementations. If uniformly applied, these guidelines will eliminate the critical coding errors that lead to buffer overflows, format string vulnerabilities, integer overflow, and other common software vulnerabilities.
Le informazioni nella sezione "Riassunto" possono far riferimento a edizioni diverse di questo titolo.
Robert C. Seacord leads the Secure Coding Initiative at the CERT at the Software Engineering Institute (SEI) in Pittsburgh, Pennsylvania. The CERT, among other security-related activities, regularly analyzes software vulnerability reports and assesses the risk to the Internet and other critical infrastructure. Robert is an adjunct professor in the Carnegie Mellon University School of Computer Science and in the Information Networking Institute and part-time faculty at the University of Pittsburgh. An eclectic technologist, Robert is author of three previous books, Secure Coding in C and C++ (Addison- Wesley, 2005), Building Systems from Commercial Components (Addison-Wesley, 2002), and Modernizing Legacy Systems (Addison-Wesley, 2003), as well as more than 40 papers on software security, componentbased software engineering, Web-based system design, legacy-system modernization, component repositories and search engines, and user interface design and development. Robert started programming professionally for IBM in 1982, working in communications and operating system software, processor development, and software engineering. Robert also has worked at the X Consortium, where he developed and maintained code for the Common Desktop Environment and the X Window System. He represents Carnegie Mellon at PL22. 11 (ANSI “C”) and is a technical expert for the JTC1/SC22/WG14 international standardization working group for the C programming language.Excerpt. © Reprinted by permission. All rights reserved.:
An essential element of secure coding in the C programming language is well-documented and enforceable coding standards. Coding standards encourage programmers to follow a uniform set of guidelines determined by the requirements of the project and organization, rather than by the programmer's familiarity or preference. Once established, these standards can be used as a metric to evaluate source code (using manual or automated processes).
The CERT C Secure Coding Standard provides guidelines for secure coding in the C programming language. The goal of these guidelines is to eliminate insecure coding practices and undefined behaviors that can lead to exploitable vulnerabilities. The application of the secure coding standard will lead to higher-quality systems that are robust and more resistant to attack.
The CERT C Secure Coding Standard was developed over a period of two and a half years as a community effort and involved the efforts of 226 contributors and reviewers including a half-dozen active members of the ISO/IEC WG14 international standardization working group for the programming language C, the Chairman and Vice Chairman of PL22.11 (ANSI "C"), representatives from the Open Group, USENIX, Microsoft, and numerous other companies and organizations. Drafts of The CERT C Secure Coding Standard were twice reviewed by ISO/IEC WG14 and subjected to the scrutiny of the public including members of the Association of C and C++ Users (ACCU) and the comp.lang.c news group.
The results of this effort are 89 rules and 132 recommendations for secure coding in the C programming language. Most of these guidelines come complete with insecure (non-compliant) code examples, and secure (compliant solutions). The CERT C Secure Coding Standards are supported by training available from the Software Engineering Institute and other licensed partners. A number of source code analysis tools are available to automatically detect violations of CERT Secure Coding Standard rules and recommendations, including Compass/ROSE which is freely available from Lawrence Livermore National Laboratory and CERT.
The Demand for Secure Software
The Morris worm incident, which brought ten percent of Internet systems to a halt in November 1988, resulted in a new and acute awareness of the need for secure software systems. Twenty years later, many security analysts, software developers, software users, and policy makers are asking the question "Why isn't software more secure?"
The first problem is that the term software security, as it is used today, is meaningless. I have attempted to define this term, as have others, but there is no generally accepted definition. Why does this matter?
There are a variety of reasons given for why software is not more secure, such as the tools are inadequate, programmers lack sufficient training, and schedules are too short. But these are all solvable problems. The root cause of the issue lies elsewhere.
The reason more software is not more secure is because there is no demand for secure software. In simple terms, if one vendor offers a product that has more features, better performance, and is available today and another vendor offers a secure product that has less features, not quite as good performance, and will be available in six months, there is really no question as to which product customers will buy, and vendors know this.
So why don't customers buy secure products? Again, it is because the word "secure" is meaningless in this context. Why would a customer pass up tangible benefits to buy a product that has an ill-defined and intangible property?
This is the problem addressed by the CERT C Secure Coding Standard. This book contains 89 rules and 132 recommendations for producing secure code. While the application of these rules and recommendations does not guarantee the security of a software system, it does tell you a great deal about the quality and security of the code. It tells you that the software was developed to a set of industry standard rules and recommendations that were developed by the leading experts in the field. It tells you that a tremendous amount of time and effort went into producing code that is free from the common coding errors that have resulted in numerous vulnerabilities that have been reported to and published by the CERT Coordination Center over the past two decades. It tells you that the software developers who produced the code have done so with a real knowledge of the types of vulnerabilities that can exist and the exploits that can be used against them, and consequently have developed the software with a real security mindset.
So, the small problem we have set out to address in this book is to change the market dynamic for developing and purchasing software systems. By producing an actionable definition of software security for C language programs--compliance with the rules and recommendations in this standard--we have defined a mechanism by which customers can demand secure software systems and vendors can comply. Furthermore, the concept of a secure system now has value because the word "secure" has meaning.
I have participated in C language standardization efforts for the past several years as the Carnegie Mellon University representative to INCITS J11 (now PL22.11) and as a technical expert at ISO/IEC WG14 (the international standardization working group for the programming language C). The first WG14 meeting I attended was held in April 2005 in Lillehammer, Norway, where we discussed a proposal for a Specification for Secure C Library Functions. That specification would eventually be published as TR 24731-1, Extensions to the C Library - Part 1: Bounds Checking Interfaces .
Although the TR 24731-1 are "more secure," they are still susceptible to reuse. Consequently, a separate effort was started at the WG14 meeting to develop PDTR 24731-2, Extensions to the C Library - Part II: Dynamic Allocation Functions ISO/IEC PDTR 24731-2, consisting primarily of existing POSIX and Linux functions. At that time, I thought it would make sense to develop a managed string library to provide a set of dynamic allocation functions with a consistent API and propose it to WG14 for standardization. One year later in Berlin, Germany, I was told that I had come up with a good technical solution but there was no customer demand for such a library.
Minutes later, during a break, I had a "Mean Joe Green" moment in the hallway when Tom Plum approach me and suggested that perhaps the C programming community would benefit from CERT developing a secure coding standard. I immediately saw the wisdom of this proposal. The C99 standard is a authoritative document, but the audience for it is primarily compiler implementers and, as been noted by many, its language is obscure and often impenetrable. A secure coding standard would be primarily targeted towards C language programmers and would provide actionable guidance on how to code securely in the language.
Community Development Process
The development of a secure coding standard for any programming language is a difficult undertaking that requires significant community involvement. The following development process has been used to create this standard:
This development approach has been highly successful with numerous individuals and organizations contributing their time and expertise to the project. As a result of this process, The CERT C Secure Coding Standard has achieved a level of completeness and thoroughness that would not otherwise be achievable by a single author, or even a small team of authors.
The main disadvantage of developing a secure coding standard on a wiki is that the content is constantly evolving. This is great if you want the latest information, and you ware willing to entertain the possibility that a recent change has not yet been fully vetted. However, many software development organizations require a final document before they can commit to complying with a (fixed) set of rules and recommendations. This book serves that purpose, as Version 1.0 of the CERT C Secure Coding Standard.
With the production of the manuscript for this book in June of 2008, Version 1.0 (this book) and the wiki versions of the Secure Coding Standard began to diverge. Because both the C programming language and our knowledge of how to use it securely is still evolving, CERT will continue to evolve the CERT C Secure Coding Standard" on the secure coding wiki. These changes may then be incorporated into future, officially released versions of this standard.
The CERT C Secure Coding Standard provides developers with guidelines for secure coding in the C programming language. These guidelines serve a variety of purposes. First, they enumerate common errors in C language programming that can lead to software defects, security flaws, and software vulnerabilities. These are all errors for which a conforming compiler is not required by the standard to issue a fatal diagnostic. In other words, the compiler will generate an executable, frequently without warning, and the resulting code executable will contain flaws that may make it vulnerable to attack.
Second, this coding standard provides recommendations for how to produce secure code. Failure to comply with these recommendations does not necessarily mean that the software is insecure, but if followed these recommendations can be powerful tools in eliminating vulnerabilities from software.
Third, this coding standard identifies non-portable coding practices. Portability is not a strict requirement of security, but non-portable assumptions in code often result in vulnerabilities when code is ported to platforms for which these assumptions are no longer valid.
Guidelines are classified as either rules or recommendations. Guidelines are defined to be rules when all of the following conditions are met:
Implementation of the secure coding rules defined in this standard are necessary (but not sufficient) to ensure the security of software systems developed in the C programming language.
Recommendations are guidelines or suggestions. Guidelines are defined to be recommendations when all of the following conditions are met:
The set of recommendations that a particular development effort adopts depends on the security requirements of the final software product. Projects with high-security requirements can dedicate more resources to security and are consequently likely to adopt a larger set of recommendations.
To ensure that the source code conforms to this secure coding standard, it is necessary to have measures in place that check for rules violations. The most effective means of achieving this is to use one or more static analysis tools. Where a rule cannot be checked by a tool, then a manual review is required.
The CERT C Programming Language Secure Coding Standard was developed specifically for versions of the C programming language defined by
Most of the material included in this standard can also be applied to earlier versions of the C programming language.
Rules and recommendations included in this CERT C Programming Language Secure Coding Standard are designed to be operating system and platform independent. However, the best solutions to secure coding problems are often platform specific. In most cases, this standard provides appropriate compliant solutions for POSIX-compliant and Windows operating systems. In many cases, compliant solutions have also been provided for specific platforms such as Linux or OpenBSD. Occasionally, we also point out implementation-specific behaviors when these behaviors are of interest.
A secure coding standard for the C programming language can create the highest value for the longest period of time by focusing on C99 and the relevant post-C99 technical reports. In addition, because considerably more money and effort is devoted to developing new code than maintaining existing code, the highest return on investment comes from influencing programmers who are developing new code. Maintaining existing code is still an important concern, however.
The C standard documents existing practice where possible. That is, most features must be tested in an implementation before being included in the standard. The CERT C secure coding standard has a different purpose. When existing practice serves this purpose, that is fine, but the goal is to create a new set of best practices, and that includes introducing some concepts that are not yet widely known. To put it a different way, the CERT C secure coding guidelines are attempting to drive change rather than just document it.
For example, the C library technical report, part 1 (TR 24731-1) is gaining support, but at present is only implemented by a few vendors. It introduces functions such as memcpy_s(), which serve the purpose of security by adding the destination buffer size to the API. A forward-looking document could not reasonably ignore these simply because they are not yet widely implemented.
C99 is more widely implemented, but even if it were not yet, it is the direction in which the industry is moving. Developers of new C code, especially, need guidance that is usable on and makes the best use of the compilers and tools that are now being developed and are being supported into the future.
Some vendors have extensions to C, and some also have implemented only part of the C standard before stopping development. Consequently, it is not possible to back up and only discuss C95, or C90. The vendor support equation is too complicated to draw a line and say that a certain compiler supports...
Le informazioni nella sezione "Su questo libro" possono far riferimento a edizioni diverse di questo titolo.
Descrizione libro Prentice Hall. Condizione libro: New. Brand New. Codice libro della libreria 0321563212
Descrizione libro Addison-Wesley Professional, 2008. Paperback. Condizione libro: New. Never used!. Codice libro della libreria P110321563212
Descrizione libro Addison-Wesley Professional, 2008. Condizione libro: New. Brand new! Please provide a physical shipping address. Codice libro della libreria 9780321563217
Descrizione libro Addison-Wesley Professional, 2008. Paperback. Condizione libro: New. book. Codice libro della libreria M0321563212
Descrizione libro Addison-Wesley Professional, 2008. Paperback. Condizione libro: New. 1. Codice libro della libreria DADAX0321563212
Descrizione libro Addison-Wesley Professional, 2008. Paperback. Condizione libro: Brand New. 1st edition. 720 pages. 9.00x7.00x1.50 inches. In Stock. Codice libro della libreria zk0321563212