Many IT security efforts fail in the short run by ignoring or even conflicting with IT users, or fail in the long run by burying IT operators under an avalanche of bewildering and disorganized details.
We were therefore pleased when two new books that avoid these errors crossed our threshold, within days of each other, even though they look at the problem from radically different perspectives. Each provides a wealth of valuable insight and practical advice for the independent developer or consultant and the in-house IT pro.
Theres a wicked and visceral appeal in the promise made by the latest title from secure-code maven Gary McGraw. His new book, co-authored with Greg Hoglund, www.rootkit.com founder and hacking guru, is brashly titled “Exploiting Software: How to Break Code” (Addison-Wesley, $49.99), and it attacks the dangerous misconception that IT security means network security.
“Most of the defensive mechanisms sold today,” the book asserts, “do little to address the heart of the problem—bad software. Instead they operate in a reactive mode.”
While millions of dollars are spent to control the perimeter, McGraw and Hoglund warn, “Network traffic is not really the best way to approach the problem.” The applications that must be exposed to the outside world, because they represent the function of a system, are rife—their research finds—with dangerous defects.
When large and critical bodies of source code become unexpectedly available for expert scrutiny, the results are often embarrassing. In his foreword to “Exploiting Software,” noted computer scientist and e-voting skeptic Aviel Rubin describes his reaction to the July 2003 source code leak at Diebold Election Systems: “Security and coding flaws were so prevalent that an attack might be delayed because the attacker might get stuck trying to choose from all the different vulnerabilities to exploit.”
Rubin hastens to add, “Such delay tactics are not recommended as a security strategy.”
But speaking of delays, McGraw told eWEEK Labs that this book took three years to write because that very proliferation of bugs across innumerable systems demands what McGraw calls “scientific organization” of attackers most effective strategies into what the book identifies as 49 “attack patterns.”
These patterns are not mere recipes for conducting specific attacks. “Script kiddies wont like this book,” the authors say toward the end of Chapter 1, “because we dont simply give away just add water hacks.”
Security guru Bruce Schneier has compared many IT attackers to thugs who buy cheap handguns without knowing—or needing to know—anything about the technology of making the weapon.
“This book is about crafting guns by hand,” write McGraw and Hoglund, adding: “Software systems are, for the most part, proprietary, complicated, and custom-made. This is why exploiting software is a nontrivial undertaking.”
But “nontrivial” though it may be to crack real systems, the books distillation of a universe of sloppy code into a physics of software attack is an effective device for making software developers face their responsibility to think about security issues.
“Most developers today remain blithely unaware of software security,” McGraw and Hoglund conclude from their real-world observations. The results, they warn, include client-side applications that assume nonhostile users, a problem they often find to be compounded by naive trust relationships that give ordinary applications “way too much systemwide privilege.”
|
IT managers should not overreact by defending every system to the limit of available technology. That would be one of the main errors targeted by the other book we want to bring to readers notice: “Security Assessment: Case Studies for Implementing the NSA IAM,” by Greg Miles and others (Syngress, $69.95).
NSA is the National Security Agency; IAM is Information Assurance Methodology, the process that NSA developed for certification of provider organizations to help it handle the exploding workload of securing federal systems.
This is the best guide weve ever seen to the real-world process of getting IT user organizations to ask themselves what types of information they use, what impact they would suffer from lack of security involving those information types and what measures they are prepared to take toward those ends.
The subtitles reference to case studies suggests these will dominate the book, but the content we found most compelling was the useful mix of conversational process guidance plus checklists and templates for conducting assessment efforts.
With “Exploiting Software” to make the dangers clear and “Security Assessment” to help organizations put those dangers in context, these books are worth adding to any IT professionals spring reading list.
Technology Editor Peter Coffee can be reached at [email protected].
Be sure to add our eWEEK.com security news feed to your RSS newsreader or My Yahoo page: