AccueilGroupesDiscussionsPlusTendances
Site de recherche
Ce site utilise des cookies pour fournir nos services, optimiser les performances, pour les analyses, et (si vous n'êtes pas connecté) pour les publicités. En utilisant Librarything, vous reconnaissez avoir lu et compris nos conditions générales d'utilisation et de services. Votre utilisation du site et de ses services vaut acceptation de ces conditions et termes.

Résultats trouvés sur Google Books

Cliquer sur une vignette pour aller sur Google Books.

Chargement...

Secure Coding: Principles and Practices

par Mark G. Graff

MembresCritiquesPopularitéÉvaluation moyenneDiscussions
1083252,182 (2.83)Aucun
Practically every day, we read about a new type of attack on computer systems and networks. Viruses, worms, denials of service, and password sniffers are attacking all types of systems -- from banks to major e-commerce sites to seemingly impregnable government and military computers --at an alarming rate. Despite their myriad manifestations and different targets, nearly all attacks have one fundamental cause: the code used to run far too many systems today is not secure. Flaws in its design, implementation, testing, and operations allow attackers all-too-easy access. Secure Coding , by Mark G. Graff and Ken vanWyk, looks at the problem of bad code in a new way. Packed with advice based on the authors' decades of experience in the computer security field, this concise and highly readable book explains why so much code today is filled with vulnerabilities, and tells readers what they must do to avoid writing code that can be exploited by attackers. Writing secure code isn't easy, and there are no quick fixes to bad code. To build code that repels attack, readers need to be vigilant through each stage of the entire code lifecycle: Architecture: during this stage, applying security principles such as "least privilege" will help limit even the impact of successful attempts to subvert software. Design: during this stage, designers must determine how programs will behave when confronted with fatally flawed input data. The book also offers advice about performing security retrofitting when you don't have the source code -- ways of protecting software from being exploited even if bugs can't be fixed. Implementation: during this stage, programmers must sanitize all program input (the character streams representing a programs' entire interface with its environment -- not just the command lines and environment variables that are the focus of most security analysis). Testing: during this stage, programs must be checked using both static code checkers and runtime testing methods -- for example, the fault injection systems now available to check for the presence of such flaws as buffer overflow. Operations: during this stage, patch updates must be installed in a timely fashion. In early 2003, sites that had diligently applied Microsoft SQL Server updates were spared the impact of the Slammer worm that did serious damage to thousands of systems. Beyond the technical, Secure Coding sheds new light on the economic, psychological, and sheer practical reasons why...… (plus d'informations)
Aucun
Chargement...

Inscrivez-vous à LibraryThing pour découvrir si vous aimerez ce livre

Actuellement, il n'y a pas de discussions au sujet de ce livre.

3 sur 3
This book explores security considerations at all stages of the software development process. The authors stress that security is not just an architecture or a design or an implementation or an operations issue. Ignoring security at any point in the development process can compromise the precautions taken during the rest of development. Security is not the responsibility of any single part of the development process or any one part of the system. Multiple layers of well reasoned security are necessary to make the system secure enough.

Notice that I said "secure enough", not "secure". The authors of this book stress that there is no such thing as a completely secure system. Security is relative to the needs of the people running the system, and those needs change over time as new vulnerabilities are discovered and as the system is used in new ways. When considering security during the development process, one should always have a plan and a goal in mind. It is not enough to make the program secure; one must know that the system needs to protect against, for example, guarantee the integrity of a company's financial information or the privacy of a user's credit card number. And it needs to do so in the face of adversaries who do not play by the rules the system sets forth.

This book is worth reading and rereading.
  eri_kars | Jul 10, 2022 |
I'm a professional software developer, for years I did IT contract and consulting jobs with focus on security related work, and for years I wrote about security for TechRepublic (eight out of my fourteen articles a month for much of that time being specifically on security topics). Even so, a good book about secure coding should teach me a lot. None of us know everything.

This book taught me very little. The one theme the authors identified as most important (treating security in the application development process as a holistic system concern) is, indeed, very important -- but that message required reminders to bring it back to the reader's mind in the course of reading the book, and much of what it discussed was strangely segregated by distinct parts of the system under development and stages of a bureaucratic, artificially modularized development process that, at the time the authors wrote the book more than a dozen years ago, was already recognized by many security and software development innovators as woefully inadequate to the needs of the time. The authors' favored software development process (which serves as the basis for the book's entire structure) is a waterfall methodology -- not only already regarded as more impediment than aid to development of high quality, reliable, secure software, but actually named "waterfall" originally in a scholarly, scathing indictment of a methodology that at the time of that denouncement was only just emerging from the bureaucratic project management soup of large corporations. That a book aiming to provide the modern (post-2000) standard for secure coding practice assumed a methodology named (by Herbert Bennington) for the sake of denouncing its toxicity to the development of quality software in 1956 is inexcusable.

All that having been said, there is some good advice in this book, and some value in the book's discussion of checklists, questions to ask yourself, and myriad approaches to assessing, analyzing, and addressing security concerns in the development, deployment, and maintenance of software systems. Unfortunately, to extract maximum value from this book would require carefully culling the worst of it, reorganizing the best, augmenting it with improvements, and writing enough material to fill the holes to end up with a whole new book. By then, the original authors would probably deserve little credit for the work.

I was, in short, disappointed. ( )
  apotheon | Dec 14, 2020 |
Good language independent review of how to write secure code. Covers a wide range of things, particularly those not covered by other books which tend to focus on a particular language, application or field.

I was given a copy at OSCon in Portland several years ago. ( )
  stuartyeates | Feb 12, 2007 |
3 sur 3
aucune critique | ajouter une critique
Vous devez vous identifier pour modifier le Partage des connaissances.
Pour plus d'aide, voir la page Aide sur le Partage des connaissances [en anglais].
Titre canonique
Titre original
Titres alternatifs
Date de première publication
Personnes ou personnages
Lieux importants
Évènements importants
Films connexes
Épigraphe
Dédicace
Premiers mots
Citations
Derniers mots
Notice de désambigüisation
Directeur de publication
Courtes éloges de critiques
Langue d'origine
DDC/MDS canonique
LCC canonique

Références à cette œuvre sur des ressources externes.

Wikipédia en anglais

Aucun

Practically every day, we read about a new type of attack on computer systems and networks. Viruses, worms, denials of service, and password sniffers are attacking all types of systems -- from banks to major e-commerce sites to seemingly impregnable government and military computers --at an alarming rate. Despite their myriad manifestations and different targets, nearly all attacks have one fundamental cause: the code used to run far too many systems today is not secure. Flaws in its design, implementation, testing, and operations allow attackers all-too-easy access. Secure Coding , by Mark G. Graff and Ken vanWyk, looks at the problem of bad code in a new way. Packed with advice based on the authors' decades of experience in the computer security field, this concise and highly readable book explains why so much code today is filled with vulnerabilities, and tells readers what they must do to avoid writing code that can be exploited by attackers. Writing secure code isn't easy, and there are no quick fixes to bad code. To build code that repels attack, readers need to be vigilant through each stage of the entire code lifecycle: Architecture: during this stage, applying security principles such as "least privilege" will help limit even the impact of successful attempts to subvert software. Design: during this stage, designers must determine how programs will behave when confronted with fatally flawed input data. The book also offers advice about performing security retrofitting when you don't have the source code -- ways of protecting software from being exploited even if bugs can't be fixed. Implementation: during this stage, programmers must sanitize all program input (the character streams representing a programs' entire interface with its environment -- not just the command lines and environment variables that are the focus of most security analysis). Testing: during this stage, programs must be checked using both static code checkers and runtime testing methods -- for example, the fault injection systems now available to check for the presence of such flaws as buffer overflow. Operations: during this stage, patch updates must be installed in a timely fashion. In early 2003, sites that had diligently applied Microsoft SQL Server updates were spared the impact of the Slammer worm that did serious damage to thousands of systems. Beyond the technical, Secure Coding sheds new light on the economic, psychological, and sheer practical reasons why...

Aucune description trouvée dans une bibliothèque

Description du livre
Résumé sous forme de haïku

Discussion en cours

Aucun

Couvertures populaires

Vos raccourcis

Évaluation

Moyenne: (2.83)
0.5
1 1
1.5
2 2
2.5
3
3.5 2
4
4.5
5 1

Est-ce vous ?

Devenez un(e) auteur LibraryThing.

 

À propos | Contact | LibraryThing.com | Respect de la vie privée et règles d'utilisation | Aide/FAQ | Blog | Boutique | APIs | TinyCat | Bibliothèques historiques | Critiques en avant-première | Partage des connaissances | 204,828,429 livres! | Barre supérieure: Toujours visible