|
|
Richard Bejtlich's Profile
Customer Reviews: 288
New Reviewer Rank: 724
Classic Reviewer Rank: 444
Helpful Votes:
4391
Views:
25971
Helpful Votes:
90
Views:
Helpful Votes:
0
|
|
Guidelines: Learn more about the ins and outs of Your Profile.
|
Reviews Written by
Richard Bejtlich "TaoSecurity.com" (Metro Washington, DC)
|
|
|
|
|
|
|
|
|
1 of 1 people found the following review helpful:
Great short book on vi, July 15, 2009
I agree with just about everything that appeared in [...] review. Jacek Artymiak has written a sort of "vi(1) for the Desperate" covering all of the aspects of vi I would like to see addressed. I could see this book used in an introductory Unix class where the students are expected to try all of the examples. Jacek posted the sample files used in the book examples at [...], so you can easily follow along.
I have one minor point that might help vi users. On p 13 Jacek discusses Switching Between Files. This vi feature is helpful when a user opens several files for editing. Users can easily move forward through a list of files using the :n command. However, the Ctrl+^ command only returns to the last file viewed. If you have three files open, for example, and you move from 1 to 2 to 3, you won't be able to return to file 1 by using Ctrl+^. However, you can invoke the :e filename command, e.g., ,:e 1, to return to file 1. I couldn't find a way to cycle back through a list of files, as you could go forward with :n. I'd like to see a future printing make this situation clear.
Anyone who uses Unix should understand vi, so I recommend this book as a resource for those who like to learn by reading a printed book and following exercises supported by example files.
|
|
|
|
|
|
|
|
|
|
|
|
1 of 1 people found the following review helpful:
Disjointed collection of chapters that doesn't practically analyze any intrusions, July 11, 2009
I must start this review by stating the lead author lists me in the Acknowledgments and elsewhere in the book, which I appreciate. I also did consulting work years ago for the lead author's company, and I know the lead author to be a good guy with a unique eye for applying geography to network security data. Addison-Wesley provided me a review copy.
I did not participate in the writing process for Practical Intrusion Analysis (PIA), but after reading it I think I know how it unfolded. The lead author had enough material to write his two main sections: ch 10, Geospatial Intrusion Detection, and ch 11, Visual Data Communications. He realized he couldn't publish a 115-page book, so he enlisted five contributing authors who wrote chapters on loosely related security topics. Finally the lead author wrote two introductory sections: ch 1, Network Overview, and ch 2, Infrastructure Monitoring. This publication-by-amalgamation method seldom yields coherent or helpful material, despite the superior production efforts of a company like Addison-Wesley. To put a point on PIA's trouble, there's only a single intrusion analyzed in the book, and it's in the lead author's core section. The end result is a book you can skip, although it would be good for chapters 4 and 10 to be published separately as digital "Short Cuts" on InformIT.
Chapters 1 and 2 are not needed. Anyone who needs to learn about networking can read a basic book already published. Ch 2 does mention that 802.1AE (if ever implemented) will hamper network traffic inspection, but you could read that online.
Ch 3 is odd because it begins by mentioning well-worn methods to evade network detection, followed by a discussion of the merits of Snort vs Bro. Someone who had to read the material in chapters 1 and 2 is not going to understand the Snort discussion, especially when it mentions byte_test, depth, regex, http_inspect, uricontent, Structured Exception Handlers, and 16 line Snort signatures. I liked seeing Bro mentioned, but the people who are going to be able to follow the sample Bro policy scripts on pages 75-78 are not the ones reading this book.
Ch 4 outlines several examples of writing signatures for Snort. This section is actually interesting, but you have to know Snort and certain advanced topics pretty well to get value from this section. Readers need to compensate for the far-too-small screenshots and lack of supporting details while reading the examples. Readers also need to figure out what the author is doing, such as when he sets up a client-side exploit against FlashGet by starting a malicious FTP server with flashget-overflow.pl. By the second example he's dropping warnings like "Had Core's advisory told you from where the size of the call to memcpy was coming, you might have to refine the signature to check for the appropriate behavior; unfortunately, the disassembly left out that argument:" [cue the ASM]. The bottom line with this chapter is this: know your audience, and write for them -- not your buddies. People who can follow contributions like this "at line speed" aren't going to read this book.
By ch 5 the "practical" aspect of this book has been left behind, with a discussion of "proactive intrusion prevention and response via attack graphs, which is really an academically-derived discussion of "topological vulnerability analysis." No one does this in the operational world, and no one will. Pages 143-144 talk about IDMEF, even though that specification died years ago. (There is still an independently-maintained -- as of Feb 09 -- Snort-IDMEF plugin. I don't know anyone in industry using it.)
Ch 6 is a generic overview of using network flows. The only new material is less than a page on IPFIX, which is just a table comparing that newer format with NetFlow. Ch 7 is called "Web Application Firewalls," but it's just an overview. Read Ivan Ristic's Apache Security or Ryan Barnett's Preventing Web Attacks with Apache if you want to know this topic. Ch 7 is titled "Wireless IDS/IPS," which is an even shallower overview than the previous topic. In none of these chapters do we have anything practical nor any intrusions analyzed. Ch 9 discusses physical security, but I didn't think it fit with the intended theme for the book.
I thought chapter 10 was interesting. Geospatial and visualization techniques do have a role in many operations, and ch 10 had the only example of an intrusion analysis. Unfortunately I don't think readers could take ch 10 and implement their own operational system. Ch 11 seemed irrelevant in light of the excellent visualization books by Raffy Marty and Greg Conti.
The book finishes with ch 12, Return on Investment: Business Justification. It was totally unnecessary: cite some regulations, list some breach costs, then compare ROI, NPV, and IRR. Talk a little about MSSPs and cyber liability insurance, then end. If you really want the best discussion of security costs, read Managing Cybersecurity Resources by Gordon and Loeb.
The subtitle for PIA is "Prevention and Detection for the Twenty-First Century." Readers will not find that in PIA. The lead author started with a kernel of a good idea, but the end result does not deliver enough real value to to readers. The lead author's material, and the chapter on Snort signature writing, could have been published as digital Short Cuts, or including in a compendium of chapters in a "survey" book. If you want to read a book intrusion analysis, you're more likely to be satisfied reading a book on intrusion forensics.
|
|
|
|
|
|
|
|
|
|
|
|
2 of 7 people found the following review helpful:
Introduction to Basic Security Monitoring in 200 pages, July 11, 2009
I must start this review by noting that the authors of Security Monitoring (SM) cite my blog and books several times, which is appreciated. I must also mention that their boss Gavin Reid, who posted a review below, has offered to sponsor my company's application to the Forum of Incident Response and Security Teams (FIRST). O'Reilly kindly provided a review copy of SM.
I think SM should be positioned as an Introduction to Basic Security Monitoring. At just over 200 pages, it's not written to be much more than that. I'm not sure I will change the mind of the reviewer who considers my first book to be "introductory," but it might help to remember that my first book is just shy of 800 pages and covers every aspect of Network Security Monitoring.
SM is technically correct, but its approach to incident detection will fall far short of what is needed in the real world. SM concentrates on a paradigm it calls "policy-based monitoring," (abbreviated PBM here) with this goal: "to compare events discovered on the network to ensure that they are approved and acceptable... PBM is practical where acceptable conditions can be documented as policies... [Y]ou must codify acceptable behavior as policies, providing a reference point against which to survey" (pp 16-17) This sounds great, but it has several real flaws.
First, PBM is mostly useful against insiders who commit fraud, waste, or abuse. What is the policy supposed to be against external threats -- "don't steal my data"? SM describes "[t]wo types of policies... used for monitoring: regulatory compliance, which involves adherence to externally enforced controls, and employee policies, which govern the security compliance of employees" (p 18).
To demonstrate how this is supposed to work in production, SM outlines the "specific items we will monitor to effect policy monitoring," in their sample company Blanco Wireless (BW), including "monitor[ing]" data center gateways to watch for signs that Social Security numbers are being transmitted over unencrypted links" (p 31). To operationalize this goal, BW implements a Cisco IPS 4255 sensor with a "custom NIDS signature to watch for unencrypted Social Security numbers on the wire" that "will match on regex for the US SSN number format ###-##-#### if it's seen on any TCP ports" (pp 143-145). That's it. Is this serious? We all know that intruders steal SSN data in cleartext while preserving the SSN format, right? Is the reader supposed to believe that the listed IDS signature is sufficient to implement PBM, and if it is, what value is PBM? If you say it's only an example, then you've tacitly agreed this book is an introduction at best.
Second, SM buys into the digital situational awareness paradigm that I call "sufficient knowledge." In other words, if a product fires an alert for "BitTorrent protocol" (example p 95), the analyst is supposed to accept it as truth and be happy with what he or she gets from the security product. In real life this is a recipe for eternal frustration. The reason is that the analyst can't tell if this alert is trustworthy, or what he or she should do about it. On p 91 SM says "In some situations, you may want to know exactly what packet(s) triggered the alert. You may also require the packet contents from the next few packets after the alert as well."
The fact is that real security analysts will want every scrap of network traffic associated with an alert, including knowing exactly how the detection mechanism decided to notify the analyst. It's ironic that the "Keeping It Real" conclusion chapter cites Northrup Grumman's practice of collecting "full packet capture... at network choke points" on p 193. I guarantee a NG analyst who gets an IDS alert and nothing else is going to be unhappy and unproductive.
Third, some parts of the book indicate to me that the authors are fairly new to enterprise monitoring. On pp 112-114 they discuss relying on SPAN ports and say "we wouldn't dare implement this inline at the data center gateways (or distribution layer), due to the high bandwidth requirements and asymmetric paths." Networks engineers do this in ways that are safe and reliable, using taps. Later the authors complain that "occasionally a network engineer will 'steal' the SPAN," and they mention deploying an IDS inline without a tap (!) It sounds to me that the authors need to revisit the reasons why more mature operations rely on taps, even though Cisco doesn't sell them.
Aside from these issues, the book does do a good job of outlining the basic steps needed to go from monitoring nothing to monitoring something. Since something is always better than nothing in security, there is value here. The authors do a good job introducing NetFlow although coverage of v9 would have been nice. The suggestions in ch 7 regarding verifying that gear is working as expected are worthwhile. It is indeed important to "know your network" as ch 3 says. I liked the trick of sending flow-tools data into nfdump via ft2nfdump on p 52.
The bottom line is that if you are completely new to the idea that you have to pay attention to your network, you will find SM to be helpful. The caveat is that you should recognize the book is an introduction to the basics. It would have been fairly easy to recognize this aspect of the book if the authors had deployed their approach on a production network and missed their SSNs being transmitted over a non-TCP, covert, or encrypted session. The essential flaw in PBM is this: if you can define a policy for badness, why aren't you stopping it? In other words, "if you can detect it, why can't you prevent it?" In the real world this has proven to not be possible except for an exceptionally limited number of cases, making other approaches necessary.
|
|
|
|
|
|
|
|
|
|
|
|
Worth the upgrade from Hacking Exposed: Windows Server 2003, July 2, 2009
I've been reading and reviewing Hacking Exposed (HE) books since 1999, and I reviewed the two previous Windows books. Hacking Exposed: Windows, 3rd Ed (HEW3E) is an excellent addition to the HE series. I agree with Chris Gates' review, but I'd like to add a few of my own points. The bottom line is that if you need a solid book on Windows technologies and how to attack and defend them, HEW3E is the right resource.
It has been fashionable for the last six or seven years for supposedly "elite" security people to laugh at HE books. Sure, the books don't teach you how to find zero-day vulnerabilities or write new exploits. The strength of the HE series is in its approach. HE books teach you about core Windows security technologies in a manner that you usually can't find elsewhere. Then the authors explain how to attack those technologies, as a penetration tester might. Finally they conclude with recommended countermeasures, as available. You can't ask for more in a security book: how it works, how to break it, how to fix it. There's something for everyone -- admin, red team, blue team.
My personal favorite sections included Ch 5: Hacking Windows-Specific Services, Ch 7: Post-Exploit Pillaging, and Ch 8: Achieving Stealth and Maintaining Presence. I didn't think Ch 6: Discovering and Exploiting Windows Vulnerabilities was very strong. I was disappointed by Ch 10: Hacking Microsoft Client Apps. Client-side attacks have been the dominant security problem for enterprise security teams for the last five years. You could probably write a whole book titled Hacking Exposed: Client-Side or similar! If/when the authors decide to write a 4th Ed, I'd like to see more coverage of client-side apps, like Adobe Acrobat, Microsoft Office, and the like.
Overall I strongly recommend reading HEW3E. It's not a five star book but you will learn a lot reading it. The target audience includes security-conscious admins, those who try to attack Windows systems, and those who defend them.
|
|
|
|
|
|
|
|
|
|
|
|
1 of 1 people found the following review helpful:
A good book with fairly solid cases, May 6, 2009
I agree with some of the commentary by previous reviewers, but I think some of it is unduly harsh. I don't think it's strictly necessary for a book to contain brand new security techniques in order to qualify for publication. Book publishing is not the same as releasing a white paper or briefing at Black Hat. However, books should strive to *not* cover ground published in other books, or even in well-written white papers. In that respect I think Chained Exploits strikes a good balance. The book's novelty relies on presenting complete, technical examples of a variety of "intrusion missions." While not necessarily groundbreaking for experienced offensive security people, Chained Exploits will be informative for broader technical audiences.
On the positive side, I thought the cases were well written. The authors did a good job explaining the entire case, with an introduction, body, and summary. This was helpful when the cases later in the book got more complex. The nature of the cases was interesting, with a good amount of variety. On the negative side, I think Phoenix would have been caught and imprisoned fairly easily for some of his exploits. Anytime he interacted with the physical world, in person, near his home, he became an easy target for law enforcement. His computer tactics weren't too sharp either, as noted by other reviewers. I would have liked seeing the book end with a raid on his house, followed by a list of the ways he exposed his identity to the cops. On a minor note, the authors should have supplied better images to the publisher -- many are fuzzy.
If you liked the Hackers Challenge and Stealing the Network book series, and you want something a little more modern and complicated, you'll like Chained Exploits.
|
|
|
|
|
|
|
|
|
|
|
|
2 of 2 people found the following review helpful:
Broad, deep, and technically accurate, yet tedious at times, April 26, 2009
Crimeware is a collection of chapters collectively written by 40-odd security researchers. Sometimes this approach is a formula for disaster, but here the end result is a solid book that covers a broad number of topics. Because each author or group of authors know their field well, they can delve fairly deeply when necessary, and their material is technically accurate. However, some of the chapters are boring and lifeless. This book blocked my reading queue for about 4 months, which is a sign I found the text unappealing. It took a flight from Amsterdam to convince me to finish it! Still, I agree with many of the other reviewers -- Crimeware is an impressive examination of malware, on a variety of fronts.
Chapter 8: Rootkits, by Prashant Pathak, was my favorite. I've read books on rootkits before, by Pathak's chapter presented the subject in a very understandable manner. His methodical and disciplined approach seemed very effective. He explained various approaches and terms, instead of assuming the reader knew what he was discussing already. I recommend reading chapter 8 before tackling other books on rootkits.
Chapter 1: Overview of Crimeware, by Aaron Emigh and Zulfikar Ramzan; Chapter 6: Crimeware in the Browser, by Dan Boneh, et al; and Chapter 7: Bot Networks, by James Hoagland, Zulfikar Ramzan, and Sourabh Satish addressed the core malware topics I would expect to appeal to the sorts of readers who frequent my blog. While several other chapters offered novel research, these three plus the rootkits chapter are probably most helpful to those defending networks.
|
|
|
|
|
|
|
|
|
|
|
|
5 of 5 people found the following review helpful:
An excellent book, but I question the audience, December 8, 2008
There's no question that Greg Conti writes excellent books. Last year's Security Data Visualization book earned 5 stars, and I put Googling Security in the same league. Conti takes a thorough and methodical look at the privacy consequences of Google's services, incorporating technical realities and thoughtful analysis. My only question is whether this book will matter to the intended audience.
Ben Rothke's review does a nice job summarizing the book, so I won't do that here. Instead, I'd like to share this thought: do the millions of Google's users care about how Google collects and uses personal information? I argue the answer is largely "no," and I recognize that Conti's book is intended to try to change that point of view. However, I really doubt it will have that effect.
I see three main consumers for Conti's book, meaning groups of people most likely to play close attention to the technical details while trying to implement privacy-preserving countermeasures. The first includes organized criminals. A certain component of organized crime is tech-savvy, motivated, and likely to adopt practices to shield their less technical colleagues.
The second includes national intelligence services and related operatives. When reading Googling Security I thought to myself "This is a big OPSEC manual," similar to Johnny Long's great No Tech Hacking book. Google Security contains all the right material for an operative to construct a false identity, and then know how to act as safely as possible to not compromise that identity. In fact, the operative could move to the other extreme and use Google's services to construct what looks like a convincing false person, with a presence on a variety of sites.
The third group (which receives some attention in the text) includes national governments and other regulatory agencies. Even without sustained popular pressure, we have seen regulatory bodies exert privacy measures on private companies. This is probably the best route to move Google in the direction Conti would like.
One related note on nation states: Conti writes on p 4: "I view Google as the equivalent of a nation-state because of its top-tier intellectual talent, financial resources in the billions of dollars, and world-class information processing resources combined with ten years of interaction data." I reject that argument, just as I reject similar arguments regarding Bill Gates' wealth and so on. Neither Google nor Bill Gates nor any other similar actor can deny a person of life, liberty, or property. If any Google employee tried to imprison any person on behalf of "Google," he would suffer criminal charges. The tiniest nation-state on Earth has more legal power in this regard, especially when you add in other aspects of sovereignty like issuing passports, minting currency, imposing taxes, and the like.
I also think Conti fails to appreciate the benefit of putting your data in the hands of a provider. At one point Conti mentions having one's data "safe on your home computer." Safe from what? Theft? Fire? Disk failure? Intruders who convince someone to click on a malicious link? The more consumers become service users and less system administrators, the better overall level of security we will attain.
Regardless of my reservations, if you want to read the best book on how Google services impact your privacy, I strongly recommend Googling Security.
|
|
|
|
|
|
|
|
|
|
|
|
18 of 18 people found the following review helpful:
The only Nmap book you need to read, December 8, 2008
Earlier this year Fyodor sent me a pre-publication review copy of his new self-published book, Nmap Network Scanning (NNS). I had heard of Fyodor's book when I wrote my 3 star review of Nmap in the Enterprise in June, but I wasn't consciously considering what could be in Fyodor's version compared to the Syngress title. Although the copy I read was labelled "Pre-Release Beta Version," I was very impressed by this book. Now that I have the final copy (available from Amazon) in my hands, I am really pleased with the product. In short, if you are looking for *the* book on Nmap, the search is over: NNS is a winner.
I've reviewed dedicated "tool" books before, including titles about Snort, Nessus, and Nagios. NNS dives into the internals of Nmap unlike any other title I've read. Without Nmap author Fyodor as the author, I think any competitor would need to have thoroughly read the source code of the application to have a chance at duplicating the level of detail Fyodor includes in NNS.
Instead of just describing how to use Nmap, Fyodor explains how Nmap works. Going even further, he describes the algorithms used to implement various tests, and why he chose those approaches. The "Idle Scan Implementation Algorithsm" section in Ch 5 is a great example of this sort of material. I will probably just refer students of my TCP/IP Weapons School class to this part of NNS when we discuss the technique!
One of the best parts of NNS, mentioned but explained in no other text, is the Nmap Scripting Engine (NSE). Ch 9 is all about NSE, with a brief intro to Lua and excellent documentation of using and building upon NSE. Beyond this groundbreaking material readers will find many examples of Nmap case studies from users. This and other sections help make NNS a practical book, showing how people use Nmap in their environments for a variety of purposes.
If you use Nmap, for any reason, you should buy this book. Everyone (except author Fyodor) will learn something about network reconnaissance from this text.
|
|
|
|
|
|
|
|
|
|
|
|
4 of 5 people found the following review helpful:
A disjointed rehash of earlier material, December 7, 2008
The Addison-Wesley Software Security Series is generally a great collection, with titles like Software Security: Building Security In (my rating: 5 stars), Rootkits: Subverting the Windows Kernel (my rating: 4 stars), and Exploiting Software: How to Break Code (my rating: 4 stars). I particularly liked the first of those three (SS:BSI), which I reviewed last year. I felt Gary McGraw wrote "a powerful book with deep truths for secure development." Software Security Engineering (SSE), by a collection of authors, pales in comparison to SS:BSI. You can skip SSE and stick with SS:BSI.
I started reading SSE very closely, underlining key concepts and looking for important ideas. About halfway through the book I realized it was mainly a collection of ideas from other sources. Very rarely do I read books that successfully present a dozen approaches to the same problem. What usually happens (as is the case with SSE) is the reader is left reading overlapping material and fragmented points of view. Frequently I found myself wondering "so what am I supposed to do with this? Where do I start? What approach matters?"
It is especially problematic when a book contains articles essentially republished from magazines. Each article author needs to frame the problem to make sense for the short period during which he has the attention of the reader. That works for a stand-alone article, but it doesn't work when all of these previously stand-alone articles are collected in one book. I can accept a book published as a series of independent works, with an editor overseeing the affair. I can't accept a book published as a single work, with magazine articles inserted at various intervals. It's incoherent and confusing.
Still, I found a few ideas interesting. Page 79 (a reprint of a 2004 IEEE article) says "Security is an emergent property of a system, not a feature. This is similar to how 'being dry' is an emergent property of being inside a tent in the rain. The tent keeps people dry only if the poles are stabilized, vertical, able to support the weight of wet fabric, and so on. Likewise, the tent must have waterproof fabric that has no holes and is large enough to protect all the people who want to stay dry. Lastly, all the people who want to be dry must remain under the tent the entire time it is raining. Whereas it is important to have poles and fabric, it is not enough to say, 'The tent has poles and fabric, thus it keeps you dry!'"
Page 73 (a reprint of a 2006 Build Security In article) says "When security requirements are considered at all during the system life cycle, they tend to be general lists of security features such as password protection, firewalls, virus detection tools, and the like. These are, in fact, not security requirements at all but rather implementation mechanisms that are intended to satisfy unstated requirements, such as authenticated access."
Page 59 (another reprint of a 2006 BSI article) says "Software can be designed and developed to be extremely secure, but if it is deployed and operated in an insecure fashion many vulnerabilities can be introduced. For example, a piece of software could provide strong encryption and proper authentication before allowing access to encrypted data, but if an attacker can obtain valid authentication credentials he/she can subvert the software's security. Nothing is 100 percent secure, and the environment must be secured and monitored to thwart attacks."
Pages 39-40 say "In software systems that include acquired or reused (commercial, government off-the-shelf, open-source, shareware, freeware, or legacy) binary components, application defense techniques and tools may be the only cost-effective countermeasures to mitigate vulnerabilities in those components."
Page 35 says "Maliciousness... makes the requirements of software security somewhat different from the requirements of safety and reliability. Failures in a reliability or safety context are expected to be random and unpredictable. Failures in a security context, by contrast, result from human effort (direct, or through malicious code)."
If you want to read a good overall book on software security, read McGraw's SS:BSI.
|
|
|
|
|
|
|
|
|
|
|
|
5 of 5 people found the following review helpful:
Candidate for Best Book Bejtlich Read in 2008, November 2, 2008
Malware Forensics is an awesome book. Last year Syngress published Harlan Carvey's 5-star Windows Forensic Analysis, and now we get to enjoy this new title by James Aquilina, Eoghan Casey, and Cameron Malin, plus technical editing by Curtis Rose. I should disclose that I co-wrote a forensics book with Curtis Rose, and I just delivered a guest lecture in a class taught by Eoghan Casey. However, I still call books as I see them, regardless of the author. (Check out my review of Security Sage's Guide to Hardening the Network Infrastructure for proof.) I can confidently say that anyone interested in learning how to analyze malware, or perform incident response, will benefit from reading Malware Forensics.
I imagine that code-savvy investigators probably don't need to read Malware Forensics. However, this is not a book for newbies. The target audience includes those doing intrusion analysis on Windows and Linux who want to focus directly on examining malicious code. An investigator whose world revolves around reviewing hard drives with EnCase will probably not understand Malware Forensics. An investigator who needs guidance on identifying and then understanding malware will definitely like this book.
The front cover emphasizes the book's "practical, hands-on" nature. I admit that I tried to follow along in many parts, usually by retrieving various Windows tools to try on malware caught in my spam folder. I do not expect the reader to become an expert in any one area of analysis, but I do applaud the authors for exposing readers to just about every aspect of malware analysis you might expect. The book uses large and small cases, multiple sample analyses, and extensive tool output to guide readers. Even the legal chapter covers the questions most of us are likely to ask.
Furthermore, how often does one read an introduction (through p xxxvi) that is educational? I loved the points about DNA tests destroying evidence and the discussion of what is "forensically sound" on p xxv, and the mention of "evidence dynamics" on p xxvi. I got the sense the authors were real forensics experts, not strictly malware geeks. The citing of non-infosec sources when making points showed me they understood the big picture (p xxxi). They also cited their tools with footnotes and URLs, and included chapter end-notes.
I found very little to complain about in this book. I noticed awkward placement of commas in chapters 3 and 8. A copyeditor could have removed those. From what I can see, the authors appreciated Curtis Rose's involvement. Syngress should observe the value of an editor who seriously reviews the text. (The last page of the book even includes errata that couldn't make it into the previous text!)
I am seriously considering Malware Forensics as my Best Book Bejtlich Read in 2008. If it doesn't win (stay tuned for announcements at the end of December) Malware Forensics will be one of the top four for the year.
|
|
|
|
(Metro Washington, DC)
