Customer Reviews

Endpoint Security

5 star:		(1)
4 star:		(1)
3 star:		(3)
2 star:		(0)
1 star:		(0)

 

 

I really looked forward to reading Endpoint Security. I am involved in a NAC deployment, and I hoped this book could help. While the text does contain several statements that make sense (despite being blunt and confrontational), the underlying premise will not work. Furthermore, simply identifying and understanding the book's central argument is an exercise in frustration. Although Endpoint Security tends not to suffer any technical flaws, from conceptual and implementation points of view this book is disappointing.

This is a tough review to write, because the non-product-specific chapters (1-7) are conceptually all over the map. Let me start with the items I found true and useful in Endpoint Security. I appreciated this perception on p 15: "I don't agree with the notion that the perimeter has disappeared. It's just moving too fast to see." This is true on p 20: "[B]asic engineering processes aren't at work in the security industry... We continue to suffer failures, and we have no way of knowing when our security solutions are successful." And this, on p 33: "[W]e've failed the first test because we can't describe secure... because we don't understand the problem well enough, we don't have a way to predict success; the converse is that we can't predict failure." And this, on p 34: "[W]e, the security industry, are not using sound engineering or the scientific method to figure out what is wrong. Worse yet, we continue to make the same mistakes year after year. We rely on the vendors to tell us what the solution should be instead of turning the formulation of a solution into a science." I loved this, on p 39: "[M]any people honestly believe that the network is too complex to understand and that 'security' is the purview of hackers and vendors. I've actually had security people tell me in meetings that their network is too large, too distributed, and too complex to identify all the endpoints on it!" By now I was excited; I thought we had a winner.

In reality, on page 1 I knew Endpoint Security was going to have problems. The author starts by using an HVAC system as a process model. He completely ignores that an HVAC system is not being attacked by intelligent adversaries. If your model does not account for the creativity, persistence, and rule-breaking of an intelligent adversary, then your model will fail in the real world. For example, on p 39 the author says "This is not how engineers do things, and for all practical purposes, no matter how we got here, we are engineers." This is not true; if we are engineers at all, we are combat engineers -- and our systems are being assaulted. Building on the HVAC idea, the author tries to introduce control theory and closed-loop process control (CLPC) (without really saying what an "open" loop looks like). I say "tries" because his "explanation" makes no sense, despite the use of examples. I found the coverage on Wikipedia to get to the heart of the issue quicker and clearer. For example, the author mentions "PID" on p 55 and 64, but only expands the acronym on p 73 to show PID means proportional-integral-derivative. On p 46 he mentions "proportional process control methodology" as if the reader should know what this means. I found myself wondering if several sections were written out of order, and I only pieced together the argument by flipping around.

To save you the same trouble, the author's premise is that networks need a "basic proportional control," meaning "protocols, hardware, and software ... [that] automatically reconfigure themselves based on our dictated policy" (p 79). NAC is a means to "close the loop" by having a "basic proportional control" that ensures "each time the endpoint connects to the network... it represents a minimum level of compliance with corporate security policy" (p 175).

The huge conceptual holes in Endpoint Security are 1) the assumption that "feedback" for CLPC is reliable and trustworthy; and 2) compliance = integrity = trustworthiness. Regarding 1, the author is in one place bashing vendors, and in another relying on vendors to produce anti-virus, IDS, and other mechanisms to be reliable -- or else his model fails! For example, p 62 states "we can make some basic assumptions about our network: A) We have a system for probing our network for vulnerabilities; B) We have some way of identifying intrusion attempts." While A is possible to some degree, it is impossible to simply "assume away" the problems of B. An IDS isn't a thermometer that accurately reports temperature.

Regarding 2, Endpoint Security states on p 78 that answering the following questions "yes" means a "minimum level of trust." In brief, they are patched? firewalled? anti-virus? authorized applications? and authorized user? Unfortunately, answering "yes" to these questions does very little to presume the endpoint is trustworthy. Sadly, the author mocks Microsoft's (correct) stance on this issue. On p 172 Microsoft says "Network Access Quarantine Control is not a security solution. It is designed to help prevent computers with unsafe configurations from connecting to a private network, not to protect a private network form malicious users who have obtained a valid set of credentials."

Conceptual issues aside (and there are more, like calling embedded devices or handhelds "threats" instead of "assets" with "vulnerabilities" and "exposures"), Endpoint Security has practical problems. Each chapter on specific technologies features sections called "initial health check." The idea is to run these "tests" to validate integrity in case you don't start with a clean build. That is a recipe for disaster, and some of the book's recommendations are laughable. If your rootkit detection methodology relies on comparing netstat and Nmap output, you're going to lose. The Windows chapter is decent, but looking at a handful of registry keys is no way to assess security. (Check out Harlan Carvey's recent book instead.) The Linux chapter is sad; who uses Xandros as a commercial Linux distro? Why not use Red Hat Enterprise Linux (emphasis on Enterprise). Who remotely administers a Linux box with VNC? Mac OS X is not a FreeBSD variant; kernel mode rootkits written for FreeBSD will not work on Mac OS X. Worse, the author cannot recommend any host integrity tools (p 119); if this is true, how can the integrity of a host be assessed? Using those five criteria mentioned earlier? Forget it.

Worst of all, the author builds his entire model on implementing CLPC via NAC, relying on "closing the loop" as "the missing link" to security nirvana. Yet, when we read the product specific chapters (Windows, Linux, Mac OS X, PDAs/Smartphones, and Embedded) only Windows can "close the loop." Is this for real? Build a model and then say it can't be done right now? I appreciate the desire to look ahead, but why did I just read this book?

I didn't give this book 2 stars, because I reserve that rating for books with glaring technical errors. Endpoint Security gets 3 stars for its sound observations of the security space (listed above), but I found the rest of the book not worth reading (although I read the whole thing). I cannot fathom how the reviewers and editors of this book allowed such a confusing argument and unworkable premise and prescription to be published.

PS: The story about the "Patent Office" on p 13 is an urban myth; Google "Charles Duell".

I think that Richard Bejtlich hit the nail on the head with his review. The book makes some sound points, like "we rely on the vendors to tell us what the solution should be instead of turning the formulation of a solution into a science" and "as devices connect to or leave the network, the perimeter changes, and so our security policy must adapt" but these aren't necessarily new ideas. The sound points are heavily diminished by the book's lack of focus. Its hard to say that he jumps around in a chapter because "the chapters" are laid out well and cover what they say they are going to cover but I kept reading waiting for him to get to the point of how to make my network and endpoints more secure. I got to the end of the book and I don't feel we ever got there.

The short answer is that he recommends using system hardening (baselining) and a NAC device to ensure secure configurations to protect your endpoints. He says end point devices are anything that extend outside your perimeter, the author breaks these up into:
Windows, Non-Windows, Embedded (printers, routers), mobile phones & PDAs, Palm, blackberry, windows CE/windows mobile, and Symbian OS. I had a couple of issues with his using a NAC as the end all, be all solution. For the sake of argument I'll concede that a NAC solution should protect my LAN from someone walking in an plugging in an unauthorized device or keeping a client that does not meet my specifications off the LAN by quarantining them (even though Ofir Arkin has spent plenty of time proving this isn't necessarily the case). What the NAC solution doesn't protect against is a public facing server with a vulnerability, those million client side "i got you to click on my link" exploits, or protect the network from any mobile devices (AV ends up being our only solution minus any baselining we can do).

I had issues with his unwaivering trust in NAC solutions and those agents that most of the time make that happen. Ch 6 starts off interestingly enough talking about how he doesn't trust software VPN solutions because they can have flaws but all throughout ch5 we are told to use NAC solutions that require a closed source agent to be installed on the endpoint. What gives? I'll take a mature open source solution over a relatively young closed source solution any day.

The book has chapters (8-12) on baselining Windows, OS X, Linux, Embedded Devices (Printers), and Mobile Devices. While not technically incorrect, its adds very little to existing information and is certainly not enough information to confidently lock down any of the systems mentioned. The Mobile Device threat and mitigation section which is probably the biggest threat to the current network is covered much better in BlackJacking. I was also disappointed to see nmap version 3.00 being used for scanning. Nmap v3.0 is years out of date.

My last set of gripes is with the author's assertion that we need to change our network diagrams (page 60). He says that we should throw out the Visio type diagrams and go with an engineering/circuit board type diagram. I found myself having to keep flipping back to see what the symbols meant. He gave the example of if you asked 3 network engineers to draw a diagram of a network you would get 3 different diagrams, but I would say that it doesn't matter if they use a firewall with a wall and flame or a wall with hatch marks 9 out of 10 times everyone will recognize that as a firewall where his version of a firewall that is two triangles with their point's meeting may not be recognized. The informIT site used to have Chapter 3 as a preview so you could see for yourself (wasn't working when I wrote this).

The book does have some good points, the idea of the ever changing perimeter that includes mobile devices as endpoints is a good way of looking at the current problem we have on hand. I also agree with the author on page 69 that "we have many security tools that can function as integral and derivative controls, but these tools are acting independently of each other and are not tied to a central controllable proportional process." I think he raises some good points but doesn't quite deliver on a solid way to fix those points in the book.

The thing that does this book the most damage is the cover, the quote at the top says if you can read only one book before deciding on a NAC solution, make it this one.

Trust me, don't make this the one book you read. There is some good stuff in this, but I found I kept thinking, "and your point would be?"

Now, I need to be honest, I gave up somewhere in chapter 11, but I read the first half of the book twice thinking it would go better the second time.

One of the problems is the way the book uses charts and graphics, I am looking at figure 2-1 on page 27 for the third time and I would still be hesitant to say I "get it" enough to try to explain it to anyone else. On the next page is a terrible graphic of a fat plastic blob in a bikini with a caption saying sexy bikini-clad beauty. By the time I got to page 60 with the symbols that look a bit like circuit design, and have titles like "bang-bang", and "peer connector traffic neutral" I was done with pictures.

Don't get me wrong, there is good material in this book, I am sure the author knows his stuff, but you will have to struggle with cognitive dissonance to dig out the pearls.

If you happen to see this book in the book store, the forward by Howard Schmidt is a fun read.

I'd like to thank Mark Kadrich for such a fruity and helpful book for everyone looks to lock down endpoints. From my experience with computer security, I alway find the problem starts from the endpoint itself. If you did correctly, you'll win. I'm dealing with malwares everyday, and I found this book very nice in describing the problem. highly recommended.

Aa'ed Alqarta

Symantec STS (Symantec Endpoint Protection)

http://extremesecurity.blogspot.com

I consider Mark Kadrich's book Endpoint Security a major contribution to the information security profession, and have ordered copies for our IT Security staff. He takes the electrical/mechanical engineering concept of Closed Loop Process Control (CLPC) and shows how to apply it to information security. While one can easily take issue with how well this concept can be applied to information security, I predict this paradigm will take hold and Mark's book will be seen as the defining event that introduced this concept into the information security profession.

The book starts with simple and humorous illustrations of CLPC from other disciples, establishes the basic concepts, and then goes on to apply that to information security. Structurally each chapter begins with a summary of what it purports/addresses, and then proceeds to support the summary position The latter half of the book is a survey of endpoint devices and some of the security issues associated with them. This part of the book is a very good guide for both technical and non-technical people who need to know how to deal with all the various types of devices being connected to their network

On a quick second pass over this book I noticed another innovative contribution that can easily be overlooked in the midst of all the discussion about endpoints, networks, CLPC, etc, and that is the introduction of a set of security and networking diagram icons that can be used to describe sources and sinks of data, network devices, etc. Using these icons, Mark is able to give clear graphical representations of his concepts. Again, while one can easily take issue with his graphics and argue if the set of icons is complete, etc. the whole notion of having a standard set of icons for describing this environment is very innovative and easily the subject of an entire book. This is a little jewel buried in the larger context of this book.

While I at times found Mark's writing style a bit jarring, I also found it very refreshing and I started looking forward to his next "tell-it-like-it-is" comment. Some may not like his style, and I encourage them to step over that reaction and go for the meat of the book - it is well worth it and does not change the essence of what Mark is trying to say. . Mark has a lot to say on a lot of topics and uses that material to liberally illustrate his ideas throughout the book.

For me, the main contribution of this book is that it takes a step back from the current cycle of information security problems and solutions, and takes a fresh, larger view of the problem space and considers a new approach - and how that approach can help address many of the issues facing information security professionals today.