Slashdot Mirror
Network Security Assessment
With those two tests in mind, Network Security Assessment (NSA) passes with honors. The terms bulletproof or hacker-proof are not found at all. And at 355 pages in length, the book's discussion of nmap starts on page 324; a good sign indeed. NSA is written for a person who needs a thorough introduction to performing network assessments, but does not need the elaborate background that the Hacking Exposed series offers. The book's technical requirements are not that extensive; a basic understanding of security, IP networks, and generic networking is enough to understand the core concepts of the book.
The book's preface starts out with a simple fact, one that is not always obvious to many: It is never impossible for a hacker to break into a computer system, only improbable. When designing and security a network, it is the job of the security architect to maximize that level of improbability as much as possible. Anyone who makes their network even a little bit more security resilient will quickly find a drop in the number of security breaches.
The publication of Hacking Exposed a few years ago started a new era in books about network scanning. Hacking Exposed was the first popular book that detailed how to go about performing a penetration test. In a similar vein, NSA is comparable to Hacking Exposed in that it provides a framework for doing security assessments. The big difference is that NSA provides a much more structured approach to performing the assessment, whereas Hacking Exposed lacked that formal approach. Hacking Exposed also goes into more details in many areas, and its initial title has morphed into many other different titles.
This more formal approach is manifest in the books 14 chapters. The first two chapters of NSA start out with the fundamental need and requirements for performing a network security assessment, and then details the tools and methodologies required to bring that assessment to fruition.
Chapter 3 details the ins and outs of network enumeration and also shows how to use standard utilities such as whois and nmap for network enumeration. Perhaps one of the most beneficial features of the book is the selection of countermeasures that are found at the end of each chapter. These countermeasures are very useful in ensuring that any vulnerabilities are appropriately fixed.
Besides listing methods which an intruder might use to elude common security applications, the book also goes into numerous hacking tools. While some may see this as providing fuel to the fire, it is clear that the tools are readily available (and have been for years). Listing of such tools won't make hacking easier for miscreants and script kiddies; rather it provides a level playing field for systems administrators who need to defend against such hackers.
After network and host enumeration, NSA steps forward into topics such as dealing with web servers and CGI, remote access issues, and ftp and database security issues. Chapter 9 does a good job of focusing on Microsoft Windows security issues. While entire books have been written about weak Windows security protocols such as NetBIOS, SMB and CIFS, NSA does a good job encapsulating ways to keep vulnerabilities here in check. Readers are highly advised to put the Windows networks services countermeasures listed at the end of the chapter into use.
Chapters 10-12 deal with the myriad security issues with email, VPN and RPC issues. While most of the information in these chapters (and the book as a whole) has been elucidated elsewhere, there is nonetheless a lot of valuable information contained in the chapters.
Chapter 13, "Application-Level Risks," is important in that many organizations put far too much emphasis on security the perimeter and forgetting about the application. The need for more emphasis on application-level security is eloquently put by Marcus Ranum when he notes that "these days, with the kind of plug-ins that come in your typical browser, combined with all the bizarre undocumented protocols used by new Internet applications, make it highly unlikely that a firewall is doing anything more complex than a thin layer of policy atop routing. As such, the applications behind the firewall are now more critical to security than the firewall itself. Which should scare the holey moley out of you."
Chapter 14 closes the book with a methodology for running a network security assessment. The author notes that running an assessment requires more thought than simply running security tools in a haphazard manner.
Overall, Network Security Assessment provides a good framework for anyone who is serious about running network security scans to security his perimeter and interior networks. The book is written in a style that is readable and understandable style; while more of an introductory text, it does not treat the reader as a dummy.
When it comes to running a network security assessment, the methodology is often more important than the running of the tools. While there is nothing radically new detailed in NSA, it does provide an effective and comprehensive overview of the issues involved in only 355 pages. If you are looking for a to-the-point book that does not get bogged down with screen prints and meaningless hacker stories and myths, Network Security Assessment is a good place to start.
You can purchase Network Security Assessment from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
My old windows box is hackerproof. It's unplugged, under my desk being used as a footrest. I guess my physical security could get a bit lax when I fall asleep at my de..........
home of the original cupholder
That's the name of my book. Does it qualify?
Life in Orange County
Forget books. Everything you ever needed to know about nmap you can learn from this woman.
Norman Cook's Ode to Sl
Could someone explain why, technically, nothing is ever hacker-proof over a network connection? Computers are deterministic. Why is it impossible to keep something secure?
...if nmap is good enough for Trinity, it's good enough for me.
No, we have a whole series of books for that.
As such, the applications behind the firewall are now more critical to security than the firewall itself. Which should scare the holey moley out of you."
Firewalls were invented to essentially protect us from bad software engineering. Bad software engineering remains a problem. A good question is whether or not firewalls should be made more complex, or left as simple packet filters... there is simply no way for a firewall at the edge of a network to make intelligent decisions about application data flying past it.
We need fundamental advances in creating robust, secure, and self-recovering software.
I bootleg Fizzy Lifting Drinks.
No thanks, I'm going to Grandma .
Is it written in a more grammatical style than your review?
Speaking of security, to make this otherwise troll post ontopic, I broke into Rubberpants's freeflatscreen account, stole his info, and am now in the process of maxing out his credit card. Not only that, but I expect to make a good chunk of change selling his friends' email addresses to the most notorious spammers in the world. So think about it people, before giving your personal data to some shady site like this with no security.
....is to know the unknown. So unless you wrote every program you use on a daily basis operate in a vacuum with *zero* connection to the outside world, it is impossible to be "hackerproof".
-Randy
WTF? By this heuristic, my upcoming O'Reilly book on the Nmap Security Scanner will be a miserable failure. No single security tool, be it Nmap, Nessus, Snort, or any of the other most popular security tools, is a holy grail, but don't judge a book based on what page numbers they appear on. That is almost as bad as making the title words a huge consideration. I do tend to look askance at books with "hacking" or "cyber" in the title, but give them a chance anway. It is often the publisher's marketing department, and not the authors, that have the most influence in the cover. I flipped through NSA, and found it good enough to ask O'Reilly for a copy (I haven't read it yet though).
In any case, NSA does not start its Nmap coverage on page 324. Nmap has its own subsection on page 11, and a peak at the index shows that Nmap is also discussed on pages 39, 47, 58, 69, 192, 322-324, 325-326, and 354. If the location of Nmap coverage is one of your two primary considerations in buying security books, at least check the index!
-Fyodor
PS: Nmap 3.70 was just released last week, with dozens of improvements.
the book's discussion of nmap starts on page 324
...and then later...
Chapter 3 [...] shows how to use [...] nmap for network enumeration.
Are chapters one and two gargantuan, or is it just too late at night for me?
The full text of this book is available online via O'Reilly's Safari subscription service:
http://safari.oreilly.com/059600611X
This is a great service for serious readers. (I have no connection with them other than as a subscriber.)
the article says nothing can be hacker proof? seriously? nothing?
We are one consciousness experiencing itself subjectively. Back to you with the weather, Bob!
It's that simple. No matter how good the teams involved in hardware and software development, there is a virtual statistical guarantee that there is a mistake somewhere. If that mistake can be exploited over the network, you have a potentially serious vulnerability.
The best you can do is isolate your penetration risk.
Ideally you would want each network-enabled service on a distinct server. That way if there is a security risk with that service software on the platform, your penetration risk is the loss of that service. That can get expensive, so you either use chroot environments or VM's to reduce the physical infrastructure required, knowing that there is some tradeoff in the overall security because of it.
Each layer of the data center environment should be firewalled from the next so that only the expected protocols from the expected hosts are allowed deeper into your data center. This all starts at the network head, typically something like a Cisco rack that port-forwards the network services to the appropriate hardware.
In the case of a web-enabled service via Apache, plugins and hooks in Apache validate the client, handle the SSL overhead, and proxy the confirmed requests to the next layer -- web interface services (e.g. XForms, Struts, HTML/JavaScript, XML/XSD, ...). Those requests are again ideally passed through a firewall, but at very least the links between those front-end and web interface servers should be a physically seperate subnet.
Tomcat, J2EE, etc. are common web interface service toolkits. This layer is responsible for user session management and minimal authorization feedback (e.g. enabling/disabling potential user actions for the business object interfaces being presented.)
We're now through three layers of firewalling and validation, and finally hit the back-end application services. With J2EE or other gateways handling the web interface, the back-end application services could be interfaced via MQ, RPC, CORBA, J2EE, SOAP/XML, or any number of protocols.
Those back-end business application services are where you can finally do the real authentication/authorization, XA transaction management, backbone message processing, etc.
Depending on performance and security needs, there may be further layerings of business/security processing, object-relational mapping, and local or WAN database clusters.
At the very core of it with as many firewalls and layers as possible between it and the outside world is your security center -- the primary Kerberos servers that are maintained from a physically secure location. Their information is replicated to the "runtime" servers in the data center, so even if someone were able to hack through 4-6 layers of firewalls, protocols, and potential SSL tunnels, they still wouldn't be able to alter the core identity information.
There are thousands of products, packages, and libraries for working with that Kerberos identity core, including smart cards, biometric id's, etc.
Tie it in with LDAP security and you can do a pretty effective job of initial application access checking without allowing a DOS on the core service. (If you can't find the core service, you can't very well flood it, can you? Not without attracting the attention of network monitoring.)
Technically "bulletproof" is impossible, but I'd rather a few layers of Kevlar between my data and the outside world, particularly if each of those layers is provided by a different vendor using slightly different approaches to their products.
I think having a seperate OS vendor and hardware platform for each service would be ideal, but currently that's only a theory. There are equally valid arguments that having a simple VM or microkernel with multiple operating systems could be as secure.
In a sense, if you had all these systems and services on the big iron from IBM, Sun, Hitachi, HP, etc. the internal data bus can be thought of as a multi-gigabyte per second virtual netwo
I do not fail; I succeed at finding out what does not work.