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.
Preface by Betty Carty
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?
Is there a patch for Linux that implements scrubbing sensitive memory pages? At the kernel level I mean (hooked into malloc/free). Ideally I'd like to be able to mark some processes as "sensitive" (via a system call maybe) and when said process exits, Linux scrubs all their pages clean...
Computers are only deterministic when they're working properly, nothing is ever 100% going to work properly.
I think you can make an un-compromisable computer (by running off ROM, for instance*), but any net connection can be DOSed.
*well, maybe what I'm suggesting means the box in question ceases being a general purpose computing device, i.e. is not a computer.... semantics and tech both over my head here.
Books do not handle assessments at all. The reviewer assesses the book.
....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?
unplugging?
Last I checked that was still hacker proof!
Especially since bulletproof deals with physical objects, and nothing, not anything, can ever be made hacker-proof.
Really? Many black-hat hackers in prison for commiting crimes have found their cells hacker-proof. At the very least, extremely hacker-resistant.
If "disco" means "I learn" in Latin, does "discothèque" mean "I learn technology"?
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.)
and the OSSTMM (Open Source Security Testing and Methodolgy Manual) then indeed it is worth its salt.
Otherwise, more thought and more experience has been put in the OSSTMM than any book published to date.
Security Testing, Penetration Testing, and Vulnerability Assessments should be done according to a complete plan covering more than just open ports found by nmap, but you have to have the methodology to go about it, or you are as bad as the proverbial "Script Kiddie".
the article says nothing can be hacker proof? seriously? nothing?
We are one consciousness experiencing itself subjectively. Back to you with the weather, Bob!
I would argue that bad software engineering has little do to with it.
I belive we need much more to be protected from bad software purchasing decisions. The best-engineered software in the world can be out there, but if that's not what you buy, all of that engineering does you no good.
I have faith in the Linux kernel because I keep tabs on the lkml, and I know that these guys are concerned about doing a good job, and that there are some well-qualified people amoung them. I have faith on other Open Source projects for similar reasons - that even though I'm not qualified to evaluate their security, others who are, do. It is a good idea some time to skim mailing list archives for the software you use, from time to time, just to see the attitudes of developers and contributers.
For proprietary software, you have to have faith in the company that produced it. The issue then becomes how do you achieve reasoned faith in a company's software development process.
And then of course we have the just plain naughty-ware that NOBODY should install. But people do install the stuff, and sometimes they even BUY it.
The living have better things to do than to continue hating the dead.
It's quite possible to build very high security systems. With enough effort, you can take proof of correctness all the way down to the hardware level.
Nobody does this any more, because 1) the costs are very high, 2) you have to make the designs so brutally simple that you lose performance, and 3) everything becomes totally incompatible with Microsoft. . But go look at the list of systems approved under the old NSA Red Book criteria at the higher levels.
The second step is to see the books discussion and placement of the nmap tool within the book.
Why not discuss the placement of apostrophes?
and nothing, not anything, can ever be made hacker-proof
Oh yeah? My computer is completely hacker-proof. There's nothing you can do to break it. In fact, I insist you try. My IP address is 127.0.0.1. Go ahead and launch your worst exploits, DoS attacks, worms, or viruses against it -- I won't even notice the attack.
For every post, there is an equal and opposite re-post.
what I would want to see is a book on network penetration testing. Books like NSA seem more like a conglomeration of How To's and Man pages with a friendly narrator.
When designing and security a network, it is the job of the security architect to maximize that level of improbability as much as possible. No it's not it is to make sure that the level of security in the system is comensurate with the system risk.
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.
While nmap is a invaluable and important security tool; it is nonetheless but one tool in a large security toolbox. Books that place the bulk of their discussion of nmap at the beginning of a book are generally focused on the blind running of tools without insight or analysis.
I think the poster just finished reading the intro to "The Tao of Network Security Monitoring" by Richard Bejtlich.
"This book strives to not repeat material found elsewhere. you will not read how to install Snort or run Nmap. I suggest you refer to the recommended reading list in the next section if you hunger for that knowledge. I introduce tools and techniques overlooked by most authors, like the material on protocol anomaly detection by Brian Hernacki, and explain how you can use them to your advantage."
+++ATHZ 99:5:80