The centerpiece of this book is the included version of the author's "Fortify" tool - this SW DOES NOT WORK... a file the install needs has been yanked from the author's and his company Cigital's website. So the included CD FAILS halfway thru and you CANNOT run this tool, to which the book devotes many pages... that are useless. Big BIG problem for a fifty dollar book, and not a word about it on the site promoting the book or the author's website. You CAN NOT RUN and you CANNOT learn from this. Unfair to leave buyers hanging !
A required reading for anyone involved with software development and implementation. This book drills-down to security in coding and testing practices and how to avoid security related bugs and vulnerabilities. The concepts illustrated on secure coding, white box and black box testing are excellent. As a developer/architect, I thoroughly enjoyed this book and I suggest to everyone who wants to get started on secure coding and testing practices.
Couple of things I QUIBBLE with are... the book does'nt realize the emerging issues and how-to's for build/refactor security for distributed application proliferation as your it - Portals, Web Services and SOA. The way we develop software is changing, the applications are becoming more pervasive and no-longer contained standalone to a system which makes the built-in security brittle impeding the agile business requirements for application/process orchestration, b2b federation and Web based application mashups. I am sure, the author will realize those gaps in the next edition of this book.
Havingsaid - This book is still a must-read for the budding security developer who wants to focus on secure programming and testing.
What is MISSING - You will not find answers for how you do secure web-centric applications, XML Web services - message-level security, identity federation and other b2b application complexities.
The root cause of many security vulnerabilities is poorly written software. Often, software applications are written without security in mind. The logical, yet elusive, solution is to ensure that software developers are trained in writing secure code.
Software Security: Building Security In is a valiant attempt to show software developers how to do just that. The book is the latest step in Gary McGraw's software security series, whose previous titles include Building Secure Software and Exploiting Software.
In past decades, writing secure code was left to the military and banking industry. Today, with everything on networks, all sectors must get into the act.
Much of the problem is that organizations target their security elsewhere--specifically on networks--rather than on software. But so many malicious attacks are directed at software that it is foolish to leave this vulnerability exposed.
McGraw goes into detail not only about writing secure code but also about key related areas, which he terms "the seven touchpoints of software security."
These points comprise code review, architectural risk analysis, penetration testing, risk-based security tests, abuse cases, security requirements, and security operations. A major portion of the book effectively discusses these "touchpoints," making the work a recommended tool for inculcating software developers with a security mind-set.
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.
Gary McGraw's book gets my vote as the best of the six because it made the biggest impact on the way I look at the software security problem. First, Gary emphasizes the differences between bugs (coding errors) and flaws (deeper architectural problems). He shows that automated code inspection tools can be applied more or less successfully to the first problem set, but human investigation is required to address the second. Gary applauds the diversity of backgrounds found in today's security professionals, but wonders what will happen when this rag-tag bunch (myself included) is eventually replaced by "formally" trained college security graduates.
Second, Gary explains that although tools cannot replace a flaw-finding human, they can assist programmers trying to avoid writing bugs. Gary is the only author I encountered who acknowledged that it is unrealistic to expect a programmer to keep dozens or hundreds of sound coding practices and historical vulnerabilities in his head while writing software. An automated tool is a powerful way to apply secure coding lessons in a repeatable and measurable manner. Gary also reframed the way I look at software penetration testing, by showing in ch 6 that they are best used to discover environmental and configuration problems of software in production.
Third, Gary is not afraid to point out the problems with other interpretations of the software security problem. I almost fell out of my chair when I read his critique on pp 140-7 and p 213 of Microsoft's improper use of terms like "threat" in their so-called "threat model." Gary is absolutely right to say Microsoft is performing "risk analysis," not "threat analysis." (I laughed when I read him describe Microsoft's "Threat Modeling" as "[t]he unfortunately titled book" on p 310.) I examine this issue deeper in my reviews of Microsoft's books. Gary is also correct when he states on p 153 that "security is more like insurance than it is some kind of investment." I bookmarked the section (pp 292, 296-7) where Gary explained how the "19 Deadly Sins of Software Security" mix "specific types of errors and vulnerability classes and talk about them all at the same level of abstraction." He's also right that the OWASP Top Ten suffers the same problem. Finally, Gary understands the relationships between operators and developers and the importance of security vocabulary.
I was pleasantly surprised by "Software Security". I reviewed an early draft for Addison-Wesley and wondered where the author was taking this book. It ended up being my favorite software security book, easily complementing Gary's earlier book "Building Secure Software." In my opinion, Gary is thinking properly about all the fundamental issues that matter. This book should be distributed to all Microsoft developers to help them frame the software security problem properly.
This is a software engineering book. I would describe it as the stuff that was missing (security) from your favorite software engineering title whether that was from Yourdon, Booch, or Beck. My background is in software development - almost twenty years from operating systems and development tools to online banking. A little over four years ago I embarked on a crash course in security when I became convinced that software was the key to our security problem, not some new whiz -bang box on the network. When I searched for information on how to build better code from a security perspective the available literature was extremely limited. There were a couple of titles on coding practices and hacking techniques - two authored by Dr. McGraw and a third from Microsoft press- but there was really nothing on the subject from a software engineering perspective. This is the first (and only book that I know of) that introduces security as a core software discipline and is quite comprehensive in terms of covering the entire development lifecycle. Gary does an excellent job of introducing security concepts from what he terms an "artifact driven" approach thus making it compatible with just about any development process or methodology (as long as it produces requirements, designs, and code). If you are an experienced developer, architect, or manager you will find it an easy read and quite actionable in terms of things you can put in place right away.
If you are new to software development or involved with it through information security, you really should read this along with one of the classic (or newer) software engineering books so that those concepts are clear. Ask the development team that you work with for recommendations on that so that you are in synch with their philosophies as there are some subtle, but critical difference in the various development methodologies. As I mentioned, the techniques and principles outlined in this book should overlay any development methodology.
For purposes off full disclosure, I have had the pleasure of knowing Gary for several years now; in fact we met during my initial quest for just this information. He has been an invaluable mentor and this book captures an incredible amount of experience he has assembled in his career. I am confident that you will benefit from his knowledge as much as I have.
We've all heard "It's the software stupid." long enough. Practitioners finally have a place to turn, beyond a single topic such as `code review', for "what" to do.
Development Managers will find a set of activities that they can experiment with adding in order to "build security into" their software. No activity is `one size fits all', but McGraw has gone to incredible lengths to make sure that every reader will find guidance that will resonate with their environment.
Security professionals, regardless of background, have been given a much broader and more powerful toolkit with which they can attack software. Rather than attempting to deepen penetration-testing efforts, they can use the touchpoints to consider use cases, requirements, architecture, and code earlier in the lifecycle. McGraw helps readers understand the essential aspects of each activity rather than getting mired in a particular technology or platform.
After reading "Exploiting Software", Developers will have to look hard to find the gems buried in presentation of each touchpoint. If they can harvest it, I think the guidance Developers find will prove more widely applicable and useful than the principles of Building Secure Software or the specificity of Exploiting Software.
Those working for organizations that manufacture software as their product have the best chance of directly applying this guidance. Organizations that rely on using software to support their (non-IT) business may have more difficulty aligning things in order to make the guidance actionable. Here's the trick: pursuit of the philosophy this book presents is going to be difficult and frustrating. Readers are most likely to be dissatisfied with the amount of "how" in the book-especially if they've already started working on some of the suggestion and have hit a barrier.
This deficiency in "how" isn't the book's fault-it's the state of the practice; stay tuned.
Product Details :
Paperback: 448 pages
Publisher: Addison-Wesley Professional; PAP/CDR edition (February 2, 2006)
Language: English
ISBN-10: 0321356705
ISBN-13: 978-0321356703
Product Dimensions: 7 x 1.2 x 9.2 inches
More Details about Software Security: Building Security In 1st edition
or
Download Software Security: Building Security In 1st edition PDF Ebook
No comments:
Post a Comment