5 comments about Writing Secure Code.

1. I read six books on software security recently, namely "Writing Secure Code, 2nd Ed" by Michael Howard and David LeBlanc; "19 Deadly Sins of Software Security" by Michael Howard, David LeBlanc, and John Viega; "Software Security" by Gary McGraw; "The Security Development Lifecycle" by Michael Howard and Steve Lipner; "High-Assurance Design" by Cliff Berg; and "Security Patterns" by Markus Schumacher, et al. Each book takes a different approach to the software security problem, although the first two focus on coding bugs and flaws; the second two examine development processes; and the last two discuss practices or patterns for improved design and implementation. My favorite of the six is Gary McGraw's, thanks to his clear thinking and logical analysis. The other five are still noteworthy books. All six will contribute to the
   production of more security software.
   
   If "Building Secure Software" by Gary McGraw and John Viega was the Unix world's resource for secure coding, WSC2E is the Microsoft equivalent. Even as a Unix-deploying professional (who performs incident response on Windows compromises), I found plenty of OS-agnostic material to justify reading WSC2E. I especially like when the authors provide examples of what coders do wrong, followed by examples of what to do right. Remarkably for a book published in late 2002, WSC2E even explains cross-site scripting attacks afflicting major news organizations as recently as a few months ago! The rules for writing firewall-friendly applications in ch 15 were very welcome, and seldom seen elsewhere. The flaw-avoidance recommendations for technologies like RPC, SQL, and COM Internet Services were well-written.
   
   The major problem with WSC2E, often shared by Microsoft titles, is the misuse of terms like "threat" and "risk." Unfortunately, the implied meanings of these terms varies depending on Microsoft's context, which is evidence the authors are using the words improperly. It also makes it difficult for me to provide simple substitution rules. Sometimes Microsoft uses "threat" when they really mean "vulnerability." For example, p 94 says "I always assume that a threat will be taken advantage of." Attackers don't take advantage of threats; they ARE threats. Attackers take advantage of vulnerabilities.
   
   Sometimes Microsoft uses terms properly, like the discussion of denial of service as an "attack" in ch 17. Unfortunately, Microsoft's mislabeled STRIDE model supposedly outlines "threats" like "Denial of service." Argh -- STRIDE is just an inverted CIA AAA model, where STRIDE elements are attacks, not "threats." Microsoft also sometimes says "threat" when they mean "risk." The two are not synonyms. Consider this from p 87: "the only viable software solution is to reduce the overall threat probability or risk to an acceptable level, and that is the ultimate goal of 'threat analysis.'" Here we see confusing threat and risk, and calling what is really risk analysis a "threat analysis." Finally, whenever you read "threat trees," think "attack trees" -- and remember Bruce Schneier worked hard on these but is apparently ignored by Microsoft.
   
   Overall, I thought WSC2E was very thorough and comprehensive, yet accessible and authoritative. The excuses in appendix B were priceless and almost enough to justify reading the whole book, along with the security principles in ch 3. I'm also remembering the great quote on p 55: "history is a vast early warning system." Just ignore the terminology in chapter 4 and elsewhere, and hope Microsoft uses Gary McGraw's "Software Security" to correct the vocabulary problems appearing in its developers.



2. Okay overview. Not many details good for beginning programmers who are learning how to code right. Not really for understanding windows security or architecture, but then that is not the intention of the book.



3. This book concentrates on a very important subject - writing secure code for Windows. In particular it focuses on two aspects: (a) correct coding techniques and how to avoid security pitfalls, and (b) the particular Windows security API and its usage.
   For the above reason I will rate this book with 2.5 stars.
   Why not 5 stars?
   I found the text well padded with the author opinions, stories, and samples, which in many cases I felt where unneeded for me.
   I also found it very exhausting trying to fish-out from all the text, the knowledge that I felt I needed.
   Some of the motives kept on coming up. I will try to summon here few, using my words:
   1. This book is extremely important thus you must read it.
   2. This book is extremely important thus you must read it.
   3. Some developers don't understand anything about security.
   4. You cannot believe how ignorant or lazy developers can be.
   5. Most developers will give wrong answer for my next question.
   And so on...
   Many of the examples in the book show 'what NOT to do' and common mistakes rather then what to do.
   I must admit that somewhere around the middle of the book I started to read it in a selective way, trying to avoid redundant text.



4. This is a good book as it does a good job covering the different sources of software insecurities:
   
   - The classical buffer overflows on the stack and on the heap
   - Canonical issues on input
   - The least privilege principle
   - There is a brief overview on how store a secret
   
   On the last point, the authors know well the topic. If you are using cryptography to protect something in your software but just store the private key in a global variable then you are helping tremendously the job of hackers as all they will have to do is look into your executable binary to search for something that looks like a key. A security measure is as strong as its weakest element and no hacker is foolish enough to attack a cryptographic algorithm that is proven strong. Even if you store the key in a secure place, all that is needed to retrieve the key is to perform a memory dump at the right time just before the software use the key. At least, you can make hackers job harder as there is nothing you can do to make your software 100% safe against hacker if the software is valuable enough to motivate them to hack your software. All you can do by improving your software security is to buy you some time before your software is hacked. All that to say that there is not bullet proof solution against hackers but the book gives solid leads to improve software security in that aspect.
   
   In this book, there is a strong emphasis on Microsoft security technologies. The Windows Crypto API and the Microsoft OSes privileges API are described in length. If you develop on Windows and want to make your software more secure then this is an excellent book for you. If you develop on another platform, there is still something for you in this book as there are a lot of code snippets that are platform independent to improve software security such as input validation for file names to protect yourself against canonization bugs.
   
   This is a very good book about software security but I do not recommend it simply because there is a new edition of itWriting Secure Code, Second Edition.



5. I agree with a previous reviewer that the title is misleading - it should emphasize that this is primarily a book about not writing non-secure code on a Windows platform.
   
   There are many good tips in the book (which is why it didn't get one star), but for those of us who write code for other platforms (there are other platforms, BTW) it's not nearly as useful.
   
   The final example of non-usefulness are the sample code files. To get them you must download a Windows executable which requires that you click on a button accepting a license agreement; the download will then begin. If you don't happen to be running on a Windows box, no download, no code examples, no nothing. Makes the book way less useful and much more annoying to me.

5 comments about Introduction to Cryptography with Coding Theory.

1. Trappe and Washington give us a very up to date education in cryptography, circa 2005. The discourse is for a sophisticated maths student who, however, need never have encountered cryptography before. The level of mathematical treatment is good and rigourous. With theorems stated and proved at a level that should satisfy even a picky mathematician.
   
   The recent nature of the book is reflected in several places. Notably where it explains the Advanced Encryption Standard, or Rijndael. This is significant because it is endorsed by the US National Institute of Standards and Technology as the replacement for DES, in such contexts as electronic commerce. (DES is also covered by the book.)
   
   Interestingly, the authors offer a short chapter on digital cash. A fascinating look at a possible future direction of a (physically) cashless society. Other texts on cryptography rarely cover the topic, so it's good to see it here. Yes, the first implementations of digital cash largely died in the dot com crash. But the idea lives on, and may yet take fruit. It has solid intellectual foundations, as shown by the book.
   
   Then there is an even more speculative chapter on quantum cryptography. Radically different from the symmetric and public key cryptosystems described in the rest of the book. Who knows how quantum cryptography will turn out? Some very hard physical problems need to be solved.



2. The problems with this book are:
   (1) The authors failed to explain the math involved in neither rigor nor
   intuitive way. The authors frequently try to introduce algorithms before
   explaining the concepts or definition.
   
   (2) The book is a mixture of number theory, linear algebra, cryptography, mixed
   almost randomly, without proper dependency logic. Neither cryptography algorithm,
   no number theory or linear algebra concepts involved are explained clearly.
   
   (3) It is more like a notebook taken by a student. It appears that the authors
   simply submit the lecture notes for publication, none efforts were made to
   turn a lecture notes to a published book.
   
   Readers are not their students, they do not have access to the authors.
   It appears to me that this is the only explaination, since I hate to doubt the
   authors capability in writing a textbook in this field. I simply can not imagine
   a competent professor in his field writing such a confusing textbook.
   
   I hate to spend my time in writing this note, but this book wasted too much my time,
   I just hope others will be lucky that I am. My knowledge in both math and CS are above
   Master degree level.



3. I am using this book in a senior eletrical engineering course. This is an excellentally written text, though very mathematically. Even though it recommmends a calculus based course in Probability I would recommend a you also have a good grasp on working with modulus or mod (n). A course in number theory would help too. If you don't have hat then extra time should be dedicated to a course using this text.



4. The authors of the book are obviously very knowledgeable about the subject matter. This book would have worked well as a reference to lectures delivered by the authors. But for self-study, this book provides INADEQUATE mathematical explanations.
   
   My bachelor's degree is in Physics, and my commercial computer experience totals 11 years. And yet I found it hard to follow many of the mathematical assertions of the authors. If you are willing to accept the mathematical assertions on FAITH, then you will likely feel satisfied with this book. But if you want to UNDERSTAND the mathematics, and you want to be able to PROVE to yourself that the assertions and theorems are true, then you may find the explanations inadequate, as I did.
   
   This book really REQUIRES a very strong foundation in Number Theory. My Physics course was not concerned with Number Theory. If you are like me, who has not finished a college-level course in Number Theory, then you might have the same difficulty in understanding this book.
   
   The writing style of the authors does not help, either. They seldom give solved examples of the mathematical concepts they are presupposing. The end-of-chapter Exercises and Computer Problems are supplied with no feedback answers. The authors do not define two mathematical objects, that they use, and which I do not recognize.
   
   In the first several chapters, the authors make about 10 mathematical assertions that they do not prove or demonstrate. These are embedded in "explanations" seeking to explain something else. But since the "explanations" make use of undemonstrated mathematical assertions, they fail to elicit understanding in the mind of the reader.
   
   To summarize, this book is more like a textbook in support of classroom lectures, NOT for self-study seeking UNDERSTANDING of the subject matter.



5. I highly, highly recommend this book to anyone who either is taking a course in cryptography in school or wants to learn about it. It is a very well written book which clarifies a lot of basic concepts. I bought it as it was recommended by my professor in school and managed to get an A in the course. It is a good book and I think it helped me come back after a lecture and find all the matter that I needed. Good reference material.

No comments about Guide to Advanced Software Testing.

2 comments about Successful Test Management: An Integral Approach.

1. This volume is rather prescriptive, giving the LogicaCMG approach to test management. However, there is something in the volume for all, and you do not have to be part of the circle around this firm to get something from it. The proviso is that if you are NOT part of the circle around this firm, you should not possess this as the ONLY book on test management.
   
   I found the introductory chapter rather simplistic, describing the historical testing methodologies that there have been. All of these were found to be deficient, when, over the horizon gallops John Wayne, and the methodology known as Risk and requirements based testing (RRBT). That may well have been true, but "risk" has been a well recognised part of the mainstream testing for a number of years. Therefore, the justification for using RRBT is almost taken as read by the majority of those looking into the volume.
   
   Having said that, there are items that give a different insight in the pages written. This reader found the `quick scan' undertaken at the start of test planning an appealing concept. This stage is undertaken in order to build up what the authors refer to as the `Test management File'. This `file' was not well introduced, and it was some time before it was realised that this is not so much a file, but a method of organising information. A meta-file would be a better way of understanding this. Perhaps something has been lost in the translation from the Dutch.
   
   The chapter on test estimation was particularly helpful, with good sections on why estimates are often inaccurate, what items are often left out of estimates (including `test management', would you believe), and what to do if the estimate, however it is achieved, is not acceptable to the stake-holders or others who are footing the bill. At this stage, if the estimates are too high, there are very stark choices; either risk are addressed, or they are not.
   
   Key elements of RRBT is that testing can stop at any point, and if that were to happen, the BEST tests would already have been performed, giving the best value to the business. Four test types are recognised by the authors, although these do not necessarily relate to test cycles. These test types are the intake test, the basic test, the complete test, and the final test. There is an order of dependency within these; if the intake test is not successful, there is little or no point proceeding.
   
   The appendices are for the most part an excellent source of additional material. Of special note is the roles and responsibilities of those involved in testing. This would be useful in the staff selection process. One point where the supplementary material did break down was in the glossary. This is a little surprising as Erik van Veenendaal is one of the authors, with extensive experience of glossaries. It could be it was felt that a comprehensive glossary was unnecessary - perhaps this should have be stated more clearly (I did not find this sentiment referred to).
   
   The final chapter discusses the transfer activities, and discusses where lessons can and should be learnt from one testing project, to be carried on to other future testing situations. There are other sources of material available on this extensive topic; having said that, the coverage was limited.
   
   So, would I recommend the book to others? My big reservation to those outside the LogicaCMG sphere of influence is that I believe that there is no set answer, no `one size fits all' approach. Thus the answer is "Yes, .................. BUT". Have other sources of material, and question the advice given. Take what is good, and useful to you, and leave other elements. Use the volume to help you answer why you do what you do, by taking a look at something else (i.e. the LogicaCMG approach). It should be noted that some other volumes on `Test Management' also cover, for example, test techniques, which are not within the scope of the present volume.
   
   If you are within the LogicaCMG circle, the decision is clearer - buy!



2. If you are in need of a disciplined testing approach to software projects, then Pinkster et al might have merit. It is correct, as another reviewer remarked, that the text exists within the context of LogicaCMG. And that perhaps it unfairly deprecates competing testing methodologies.
   
   However, to the extent that something is better than nothing, the book offers detailed steps and metrics that you can evaluate. Some are unavoidably rough, like trying to estimate how long testing will take. But the authors give reasonable suggestions on this and other factors.

5 comments about Beyond Borders: Web Globalization Strategies (VOICES).

1. This is a fantastic book - a thoughtful and well written overview that has been needed for quite some time. I am very pleased to have it, and would recommend it to all types of people, both hands on practitioners, the curious, and to my recalcitrant clients who do not understand what about web globalization should cost money!



2. This is a solid reference book which can assist people who are planning multilingual website design and development projects. The case studies will definitely provide readers with good information from firms who have already created global websites, and the Hands-On chapters will benefit those who want to experience first hand some of the language issues you encounter when creating a multilingual web presence. I am with a firm who provides website globalization services and found Yunker's book to do a great job summarizing the issues.



3. Overall, this book to be very thoughtful, insightful, and well-organized.

   The book is a helpful introduction-- and probably invaluable to someone who wants to get into the business-- but some of the hands- on was a little lacking.

   However, it's really not geared towards those of who are decision makers at larger companies-- for example, Yunker praises the infrastructure underlying Fedex.com, but fails to mention the company that designed the infrastructure--OnlineFocus. Additionally, the ESPN comments lack any reference to Starwave's global reach and how that may have helped them design ESPN for diverse audiences.




4. First of all - I love the books cover - but the watermarked immigration/customs stamps throughout the pages can be a bit distracting. And why page numbers are only given on odd numbered pages I have no idea.
   
   This is the type of book where you read it and think - 'oh I know that already' but it really does help to have this as a reference when thinking about a multi language or culture website. Actually there are quite a few pointers that are great even if you're developing a site for just one language.
   
   The book covers a range of audiences which is great - but some of the content doesn't become specific enough - want to have a definitive list of what browsers support unicode - check the index, there are 4 sections that have content on this but unfortunately not a single definitive reference.
   
   It's a nice book to read - and for New Zealanders - we're not forgotten! Maori, and use of the Macron is mentioned, but not really discussed in great detail.



5. If you want to localize your website following advice from an author who:
   
   1) Believes that people in Iran speak Arabic;
   2) Thinks that the "circle" is an accent used in Czech;
   3) Thinks that "Czechoslovakia" still exists;
   4) Thinks that the word "flu" is not understood in the UK;
   5) Thinks that Telugo is a more important language for website localization than Italian;
   6) Thinks that Romansch is related to German;
   7) Thinks that German capitalization is "more complicated than in English"
   
   by all means go ahead.

No comments about Pro ASP.NET 2.0 in VB 2005, Special Edition (Pro).

1 comments about Peer-to-Peer Systems and Applications (Lecture Notes in Computer Science).

1. I found this collection to be a reasonable overview of developments in P2P networking over the last 6 years.
   
   However this is little original content in any of the papers. In some cases there is *no* original content. As a survey (which to be completely fair, this is what the back cover of the book claims it is) this is a fairly comprehensive work.
   
   However, it would be nice if the authors had taken the time to study their topics in more depth and provided some value added beyond collating existing work.

No comments about Microsoft Office InfoPath 2003 Kick Start.

3 comments about Practical Software Factories in .NET (Books for Professionals by Professionals).

1. I was a bit dissapointed in this book, however I still highly recommend it to anyone interested (as I am with a book of my own on the way) in factories.
   
   I was expecting far more in terms of real-world implementation, but I do understand all to well from experience that the pieces are not quite there yet. I suppose my dissapointment was in the name of the book. This is a far more theoretical 'what could be' book then 'here is how you do this now' book.
   
   That being said, they do a good job of providing a nice single resource for defining many core concepts and adding (especially to a MSFT audience) many critical knowedge areas.
   
   So bottom line, if you are even thinking about factories (and have already read the seminal work by Microsoft) then give this a read.
   
   In my book I hope to be far more 'Practical' and able to show an 'A-Z' example from iterative Factory creation to iterative factory consumption and deployment.
   
   Thanks,
   Damon Wilder Carr, CEO
   agilefactor



2. Too much theory. No sample code. I quickly got bored with this book. One of the main reason I bought this book was to learn about MS GAT/GAX which the book only mentioned. I was also interested in learning some good practices on building Software Factories of which the author explained the basis and need but no supporting sample code.



3. This book is not a user manual for DSLs or the GAT/GAX technologies. While it shows the basic technologies with small samples it is by far not comprehensive, but the book points to further resources to explore the technologies.
   The book is rather meant to describe the process on how to implement a Software Factory in an exisiting product environment. We successfully used this approach for our product development and published the results http://msdn.microsoft.com/en-us/library/cc496679.aspx .
   If you want to implement a Software Factory in your environment, read this book.....

4 comments about AutoCAD 2006 VBA: A Programmer's Reference.

1. An excellent and comprehesinve reference book for both non-programmer and programmer alike.



2. This book contains everything you need to know about AutoCAD VBA and then 10x more! I was looking for a simple guide to AutoCAD VBA syntax. This book isn't quite written for simple little utility type apps, but more for big-picture drawing automation. But given the uber-complicated nature of AutoCAD VBA, Sutphin did a GREAT job. I wish I had more time so I could follow him along for all 700 pages.
   
   I wouldn't quite recommend it for newbies personally, but if you have VBA experience, you'll be okay.



3. Joe once again did an outsdanding job of breaking things down and organizing them to make this a fantastic reference. Many readers don't pay attention to "Reference" in the title, which is exactly what this is. It's not a cook book or tutorial book, it's a VBA reference for AutoCAD. If you plan on writing VBA code for AutoCAD, you need this book.



4. By far the best AutoCAD VBA book around. I've purchased several books on this subject and this is the one that I turn to when I have a real problem. I'm a VBA hack and the examples in this book have been enough to help me solve every problem that I've had. I would recommend this book to anyone. My only problem with this book is that it hasn't been upgraded to the latest version of Acad.