Slashdot Mirror
Internet Site Security
About the authors
Erik Schetina, CISSP, is the CTO for TrustWave Corporation. He spent 14 years with the U.S. Department of Defense developing information security systems and public key cryptosystems. Jacob Carlson is a senior security engineer for TrustWave Corporation. His primary role is leading the penetration testing and vulnerability assessment team. In his copious free time he likes breaking things and writing code. Ken Green is a senior security engineer for TrustWave Corporation where he works extensively on intrusion detection systems, firewalls, and virtual private network initiatives.
When you read biographies like the ones above you can be somehow reassured that the content of the book is good. All of the authors come from TrustWave Corporation and the fact that they work together has influenced the writing of this book, in a very good way.
The basicsAt the very beginning of the book the authors show us that the starting point of building a secure environment is not the implementation of a solution but rather the defining of the assets we want to protect. You have to know what's a threat to your assets in order to choose the best security solution.
The authors manage to successfully illustrate how different things such as system administration, policy and audits fit into an overall security plan. Through the book, the authors educate the reader by making sure he sees "the big picture." The bottom line is that "the transition from a techie to a security professional consists in the recognizing the importance of all the components of security." In the second chapter some great material is covered: description of the security process, assessment and policy, asset protection, monitoring and detection.
Which one is better?When describing the way things can be done, the authors always give you the pros and the cons. For example, at one point they describe the difference when using commercial scanners in penetration testing compared to using a team of people who will do it by hand. They provide good pros and cons for both ways, and that's one of the great things about this book, you always get to look at the other side of the coin.
The insecuritiesWhat we all know is that the Internet is inherently insecure -- that's why this book was published in the first place. The authors explain why it's insecure, who administers it and how it works. Some of the topics presented here are: an overview of TCP/IP, the Domain Name Service (DNS), Whois databases, anonymity, and much more.
History is also present in this book. Chapter 4 begins with a brief overview of the history of the Internet and the TCP/IP protocol suite. Also mentioned is the Morris Worm (November 1998). As we move on, the DNS is explained in greater detail (with some security issues addressed specifically), and we are slowly presented with an abundance of technical details that stretches over several chapters. Some of the things that are explained in the book include: secure protocols, virtual private network protocols and encapsulation, the secure shell (SSH) and authentication systems.
As an inevitable part of a book of this kind, there's a part dedicated to passwords (and good rules for their generation), and another on digital certificates. The authors present the shortcomings of certificates as well as their best uses. Although neither of these are explained in great detail, you'll be able to get an overview of the things presented.
Moving on, we get a plethora of information covering: firewalls, DMZs, VPNs, external and internal threats, the security of wireless networks, workstation management issues, intrusion detection systems and log processing, etc.
Operating systemsThe book also gives some good information when it comes to operating systems and server software. Some of the covered topics include:
- Windows NT and 2000 - authentication, access tokens, security identifiers, object access control lists, tightening Windows users rights, etc.
- Linux - overview of the Linux Kernel, file system permissions, authentication mechanisms, how PAM works, etc.
- Server security: web, mail, FTP, etc.
If you want information about attacks, denials of service attacks are covered in great detail, along with many other attack scenarios. Since you also want to protect yourself from all of these attacks there's naturally much material dedicated to firewalls: their functions, implementation issues and vulnerabilities. Now that's not enough, is it? Now you want more. There's a whole chapter dedicated to intrusion detection systems and one dedicated to incident response and forensics. The chapter on incident response and forensics will be of particular interest for all of you who want more knowledge of legal and privacy issues.
Secure CodeTo complete the book, there's a chapter dedicated to the developers, which discusses the development of secure Internet applications. Here you'll be able to read about common sources of programming mistakes, exploiting executable code, application-level security, coding standards, and more.
The verdictThis book manages to shade a new light on the problems of security implementation by explaining the position of the system administrator and the position of the IT manager in order to make them both understand their role in the overall process of security in the company. It's a good idea to give it to both your IT manager and your system administrator, they will both learn from it and in the process start to understand each other on a new level. With this book, you basically learn to think on a larger scale.
There are not many downsides. There are basically only two things that I didn't like about this book: the lack of resources, and (in parts) the writing style. There are not enough resources listed, and I always like to get to more information. As regards the writing style it's obvious that this book was not meant to entertain in any way, but it sometimes seems a bit too serious. I always believed that learning should be fun. That's just me :)
Overall, this is an excellent book, two thumbs up!
If you're interested in hearing what one of the authors of the book has to say, you can check out an interview with him here. You can purchase Internet Site Security from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
"We all want 'big books'"
I thought we all wanted bigger manhood. At least that's what 30% of my spam has been promising. And for only $50!
This may have been suggested before: /. should add what the "average price" for the book is in the review summary.
I know some subjects are "priceless" for some but for the common mortals affordability is the main concern :-)
The ENIAC Demo Competition
Are always horribly obsolete.
Due to the delay between when you write a book, and it's on the shelf at the store...
There's plenty of good reading though.
The article states "We all want big books" but, I want to knwo if this is true. Lately I've been getting tired of suffering through these massive books that are being published of late. Most especially vexing is that it seems that many/most of these 1000+ page books are artificially inflated, size wise. They don't seem to have any more really valuable content than books half their size. Compound this with the fact that the wordy inflation of the books seems to make them much harder reads, not to mention taking an eternity to get through it.
So, I ask the Slashdot crowd; Do you really want big/bigger books? Or, is 300 pages plenty, provided the information is in there?
Joshua: "Do you want to play a game?"
on the shelves of my former colleagues. One fellow in particular ws adamant about collecting these books. Unfortunately, he was not as rabid about IMPLEMENTING security. My point is, regardless of the size of the book or the library, it is all worthless unless the measures outlined and detailed are followed.
If we don't fight for ourselves no one will.
Frankly, most IT books have more than 300 pages and are priced at $50 or more. Most of these, however, filled with a lot of "tricks" to increase page count - large fonts, large margins, useless chapters, you name it. Editors have to make a living, but if as the consumer we are always saying "the bigger the better", then it will only result in editors believing that "size is everything" as their daily spam suggests.
The ENIAC Demo Competition
Don't use IIS.
what were the other 1399 pages for?
Trolling is a art,
Yes, big books are kind of a trend in the computer-book realm. Where else in the bookstore would you find monstrous tomes like the ones you see on Visual Basic or Java?
:-) Much like the huge portions that restaurants now serve, people want to feel that they are getting some value for the obviously inflated prices. Even if they were only going to eat a small amount, they are happy to see a huge plate of food for their $12.
It has a lot to do with how much they charge for these books. You want $50 for a book that costs $3 to print? (I can hear the anti-RIAA trolls now
If you were to get a normal sized entree (or book) for the amount of money you are spending, you would feel that something is wrong, that you are getting ripped off somehow. Big books sell more than small books. Even if the content is the same. They will make the typeface larger and include tons of screenshots if that is what it takes to make a massive volume.
A lowly "8". Enough below the standard "9" for me to not buy this book. Sorry.
Well, here was me thinking that the morris worm was in 1988, not 1998.
-- Hulver's site
Let's look at some previous work of theirs, reprinted here
Reading this analysis, I would prefer to name this book as "Canned Internet Security". Maybe the book is good in its generic considerations about security. But I'm pretty sure that one cannot talk about Windows, Linux, Internet, Secure Programming and compress all of it into some 400 pages. Well, talking about Windows ACLs costs an expert nearly the same number of pages, you know? And that was a book for average to advanced experts. And, knowing the subtilities of both Windows and Linux, I am pretty sure that 1000 pages would not be enough to cover 10% of the problems. So ~400 pages?
Besides the fact that one chapter is about history leads me to think that this is quite a general thing. However, for people who may want a startup on security, considering the level of the authors, this book may be some good stuff for them.
at the end of the review. If you decide to buy this book consider using the /. clickthrough link. It generates revenue for the /. crew, and is a convenient way to shop. This is a new feature outside of the OSDN advertising. So support Rob and the crew directly and click on that link.
If we don't fight for ourselves no one will.
Make the book big and mostly useless, fill with so-called "useful information" and sell it at market price. - How to make decent money
....
This does 2 things:
A: It keeps good job security: Once an idiot(person with low intellect for my purpose) sees the 50+books on the shelf, each over 1k pages, he'll decide that it's a bad idea to go for an IT job. Or better, he shells out $500 for a class and finds out he's expected to read 2000 pages of text plus do a lab manual, plus tests. Makes more money for us who can endure it, or actually figure out how the stuff works.
B: Provides an invaluable recource for referencing to. You're in a bind and can't remember a prociedure, dive into that book and you can find what you need to know.
For example, I have 3 A+ cert books on my shelf. Each of them explain nada to me about the important stuff; how the processer works, how the busses work, basic electronics and binary, etc. eow most of the new stuff works becuase I never learned how the old stuff works in detail.
It's also partially dependance. If you get your cert on one line of books, you'll buy the new editions to keep upto date, ensuring the next book will sell well. However, anyone with half of a brain knows that you read reviews about the new prociedures with the new tech before it comes out. If you don't you are most likely an idiot technician, or the guy who broke the simm slot on my grandma's motherboard, called a better tech over to save your ass, and taped the sim into the slot with masking tape...then stole the dip ram out of it...
I feel the need to go down to best buy and open a can of whup-ass on their "techs"...
Candy-Coated Knowledge
Reprinted here.
This demonstrates that as an industry we have a lot of work to do in security
I think that this comment by a M$'ie is the key point. If OS people sit around patting themselves on the back because of how much more secure OS is because of all those "talented eyes" that are poring over the code, then they are going to be in for a very rude awakening. All this "your software is less secure than mine" blustering just simply points out that the overwhelming majority of software that is used out there (regardless of the religious camp from which it originated) has serious security issues. The OpenBSD camp seems to be the only ones that are making a focused effort to try to shore things up in this regard, and until others (M$ and Linux) tackle the issue with the same zeal, we'll continue to have problems.
...was 1988. I must be old if I remember that. Now someone hand me my walker and Metamucil.
Path
The surest sign of intelligent life in the universe is that none of it has tried to contact us. -- Calvin & Hobbes
Hmm, except those two links aren't the same. Are you sure you aren't just trying to pass off?
I've been involved as a developer and/or security consultant in several internet projects, and I've noticed that the main problem, most of the time, is not really technical. If you really want a secure web site, you can have one relatively easily. Of course it might not be absolutely secure, but it's very hard to break by the average hacker.
The main problem is that security is often developed at the end of the project, or completely forgotten, because it doesn't add any functionality to the application.
At the beginning of the project, a prototype is developed (without security, because the goal is to show the application functionality), then a first version (still without security, because you're in a hurry), then the whole thing is developed and someone sometimes starts thinking about security.
Since the application hasn't been designed at the very beginning with security aspects in mind, you end up adding hacks and workarounds to the application to make it a bit more secure, but it's sometimes very hard because it might break the functional spec or make the application look different than in the demo.
At the end, you often end up with a solution which uses security through obscurity: since there is no link to this administration page in the welcome page, users won't find it! BAHAHAHAHA!
JB.
My favorite way to generate passwords is to alternate random consonants and vowels. The results are just about as 'secure' as any other randomly generated password (i.e., knowing the pattern won't help very much) and much easier to remember. Social engineering is always the easiest way to break passwords, and people often write down difficult-to-remember passwords.
Some examples:
gymolifi
tosenima
qopanela
Because of the alternating pattern, the results are almost always pronouncable, which makes the passwords signifigantly easier to remember. Digits or symbols can be added to satisfy password requirements and increase security.
>We all want 'big books'
No we don't. Personally, since reading Kernighan & Ritchie, I've been convinced that good books have to be slim.
(another precondition is that it doesn't have a "Learn X in x minutes/hours/days" title)
There's plenty of good reading though
By that, I meant that the concepts, etc are still relevant. *shrugs* mods....
Much more insidious, because it speaks of the pompatus of love.
Overall, this is an excellent book, two thumbs up!
This seems kind of odd, or is it just "thumb" inflation. Two thumbs up does not mean what it used to...
I honestly will not buy a technical book in the 1,000+ page range, especially if the title:
Why? Because I know I'm unlikely digest the contents of 1000+ pages of text on one subject, if I manage to finish it. I also generally suspect large books of rehashing FAQs or other widely-available docs just to fill pages.
I don't consider myself an O'Reilly bigot, though I do lean towards their books since they tend to publish smaller, focused books. If a book is pure reference, I may consider buying it if it's 1000+ pages. Following are examples of some great books I've bought that I found very useful and readable due to their small size:
The Internet already offers me an overwhelming, disorganized pile of information on any subject--and at least it's searchable via Google. Dead tree books have use when they're usable and organized, and I've found that generally translates into a smaller book.
Did anyone notice that there is a newer book available on amazon.com than the book mentioned it the text above? The publisher is now Addison Wesley Professional and it is also a little bit cheaper. It has the same amount of pages and seems to be the same edition.
.sigh
Just my own personal experience.
It does not matter what size the technical book is, it only takes 5 pages to induce deep sleep and dooling!
Life is like an elevator, sometimes you get the elevator and sometimes you get the shaft
Not only is a big book not necessarily better; it is almost invariably worse. For simple reasons: Writing well is difficult. It takes a lot of work for an author--or a team of two or three working closely--to produce 200 quality pages. 1000 quality pages would be a monumental effort that, frankly, nobody's going to put into a book on Visual Basic. Further, concision is a mark of good writing, so when you see a big book, you should wonder, "why were they not able to get this into 200 pages?". Not to mention that a big book takes longer to read, is harder to find things in, and is less convenient to use and carry.
For most technical books, the only ways to get to 1000 pages are to write sloppily, add filler, or employ many authors working independently. The last tends to produce an incoherent whole, and make each author care less about his contribution.
The main exceptions are books with a justifiably large reference section (large because there is truly a lot of valuable material to reference, which is uncommon), and, to some extent, books that have been through several editions, whose authors have put new effort into each edition.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
Personally I am sick of big bigs. I am starting to suffer from manualitis. Id rather get a book that is shorter and comprehensive and readable than a tome that covers ALL the scenarios.
Lots of the true tech books (Fowler on UML for instance is $35 and is brilliant.
I'd say as a rule that like fine food, the best books are small compact and just tell you what you need to know.
The big books are the crap resturants of the world, lots of food... not much quality.
An Eye for an Eye will make the whole world blind - Gandhi
Tons of papers on site security
www.cgisecurity.com/lib
It's not about "finding out how much it cost" (many ways to find out :-D ), but rather about "knowing the cost at a glance".
:-)
Time is money
The ENIAC Demo Competition
Windows NT and 2000 - authentication, access tokens, security identifiers, object access control lists, tightening Windows users rights, etc.
Ok, I could have ignored this review until I got to that part.
Windows 2000 sounds like a complete, powerful system in theory. To salespeople and even project managers, Windows 2000 is packed with all of the buzzwords they want to hear. "Security Reference Monitor", "Policies", etc.
Of course, anyone with practical, in-the-trenches experience knows that it's an impossible system to keep secure. It is big, it is bloated, it is closed source. It discourages deep understanding and is too complicated and restrictive to allow you to strip down to the parts you only need.
The best reference manual you can find on Windows 2000 internals is "Inside Windows 2000", which is at best a pedestrian overview of the system. This is not the fault of the authors, it is the fault of the system.
It is simply pathetic compared to The Design & Implementation of the 4.4BSD Operating System, or Linux Kernel Source Commentary, or UNIX System Internals, et al. You cannot download the source to Windows 2000 and evaluate it for yourself. You cannot compile out support for everything but the core essentials. You cannot identify and understand every process running on the system. You do not have the option of replacing them with specialized alternatives.
Do not confuse this with Linux being unbreakable. That is not what I'm saying. I'm saying that in the hands of a competent person, one can achieve a far greater degree of security with Linux than they ever can with Windows. To some admins, this is not a big deal. To me, Windows is simply unacceptable.
The authors appear to be blinded to technical realities by buzzword compliance. Not too suprising given their background.
Many professionals are content with Windows, but anyone who is passionate about technology finds it reprehensible. It comes down to who you'd rather deal with. Would you rather hire a brain surgeon who was passionate about his craft or just one who simply treated it as a job?
why the parent post got modded down as a troll. I don't find anything particularly incindiery about what the poster said. Unlike a lot of posters here on slashdot, he actually took the time to think of something unique to say rather than repeating the same tired old arguments.
You may not agree with what he said, but I think he made his points rather well. If you disagree with what the poster said, why not post a reply?
The society for a thought-free internet welcomes you.
See: http://www.wikipedia.org/wiki/Morris+Worm
If you're interested writing secure applications for Linux/Unix systems, take a look at my free book, Secure Programming for Linux and Unix HOWTO, available at http://www.dwheeler.com/secure-programs.
- David A. Wheeler (see my Secure Programming HOWTO)
realized how much good information the authors were able to fit into just over 400 pages.
So was the content of the other 1000 pages just crap?
Looks like a typo on the date of the Morris Worm. The Morris Worm was November 1988, not 1998. Here's a link for reference.
--I've wondered why passwords have to be inputed as text. Like, is there a way to use an audio/video clip instead? Perhaps keep it stored on removable media, you input it when needed by a direct cable connection, or inserting a USB device or a pcmcia card, etc. Is this being done?
Just use a Mac. Not one exploit ever for mac webservers according to huge BugTraq database.
You cannot use the unix OS X mac OS, it has already had over 30 remote exploit weaknesses that had to be pathced.
I am talking about using a comemrcial webserver progrom on Mac OS 8.x or 9.x
9.2.2 is latet Mac OS, yet NO mac OS from 8.x through 9.2.2 has ever had one remote weakness that did not involve specific user interaction to causea problem, the defaults are very secure.
In fact so secure not one mac server has ever been compromised, though at one point a 3rd party addon cgi tool was found to be buggy and could cause a problem back in 1995 I believe. I forgot its name.
I do not care for a reply to this. Therefore by definition, it is not a troll. I am sick of linux fans moderating "0" posts to -1 because they cannot handle the fact that NOT ONE REMOTE EXPLOIT FOR MAC OS exists and has ever been published or used.
And, yes, macs are fast, and cached static pages are the same speed on almsot any OS, and Webstar 4.0 is fully featured.
This 1400 page book should mention that a mac would give you 7 years of hassle free no-exploit web serving.
Macs have no filename extensions, nor heavy usage of C strings (null terminated), nor root account, nor shell, nor dangerous way to pass return addresses, and avoid intel making hacking a little more difficult, also macs require files to have a second invisible file associated with them called "resource forks" to execute and network tools typically will not create these resource forks. There are countless reasons makes have not been exploited remotely.
I find it both sad and amusing that people try to publish books about topics without first addressing the fact that there are more secure platforms for webserving. Most of these short-sighted me-too security bandwagons concentrate onthe porous unix/linux offerings, or MS weaknesses,
:
It is a concrete fact that that no MacOS based webserver has ever been hacked into in the history of the internet.
The MacOS running WebStar and other webservers as has never been exploited or defaced, and are are unbreakable based on historical evidence.
In fact in the entire SecurityFocus (BugTraq) database history there has never been a Mac exploited over the internet remotely.
That is why the US Army gave up on MS IIS and got a Mac for a web server.
I am not talking about FreeBSD derived MacOS X (which already had a more than a 30 exploits and potential exploits ) I am talking about current Mac OS 9.x and earlier.
Why is is hack proof? These reasons
1> No command shell. No shell means no way to hook or intercept the flow of control with many various shell oriented tricks found in Unix or NT. Apple uses an object model for process to process communication that is heavily typed and "pipe-less"
2> No Root user. All Mac developers know their code is always running at root. Nothing is higher (except undocumented microkernel stuff where you pass Gary Davidians birthday into certain registers and make a special call). By always being root there is no false sense of security, and programming is done carefully.
3> Pascal strings. ANSI C Strings are the number one way people exploit Linux and Wintel boxes. The Mac avoids C strings historically in most of all of its OS. In fact even its ROMs originally used Pascal strings. As you know Pascal strings (length prefixed) are faster than C (because they have the length delimiter in the front and do not have to endlessly hunt for NULL), but the side effect is less buffer exploits. Individual 3rd party products may use C stings and bind to ANSI libraries, but many do not. In case you are not aware of what a "pascal string" is, it usually has no null byte terminator.
4> Macs running Webstar have ability to only run CGI placed in correct directory location and correctly file "typed" (not mere file name extension). File types on Macs are not easily settable by users, especially remotely. Apache as you know has had many problems in earlier years preventing wayward execution.
5> Macs never run code ever merely based on how a file is named. ".exe" suffixes mean nothing! For example the file type is 4 characters of user-invisible attributes, along with many other invisible attributes, but these 4 bytes cannot be set by most tool oriented utilities that work with data files. For example file copy utilities preserve launchable file-types, but JPEG MPEG HTML TXT etc oriented tools are physically incapable by design of creating an executable file. The file type is not set to executable for hte hackers needs. In fact its even more secure than that. A mac cannot run a program unless it has TWO files. The second file is an invisible file associated with the data fork file and is called a resource fork. EVERY mac program has a resource fork file containing launch information. It needs to be present. Typically JPEG, HTML, MPEG, TXT, ZIP, C, etc are merely data files and lack resource fork files, and even if the y had them they would lack launch information. but the best part is that mac web programs and server tools do not create files with resource forks usually. TOTAL security.
4> Stack return address positioned in safer location than some intel Osses. Buffer exploits take advantage of loser programmers lack of string length checking and clobber the return address to run thier exploit code instead. The Mac compilers usually place return address in front or out of context of where the buffer would overrun. Much safer.
7> There are less macs, though there are huge cash prizes for cracking into a MacOS based WebStar server (typically over $10,000 US). Less macs means less hacker interest, but there are MILLIONS of macs sold, and some of the most skilled programmers are well versed in systems level mac engineering and know of the cash prizes, so its a moot point, but perhaps macs are never kracked because there appear to be less of them. (many macs pretend they are unix and give false headers to requests to keep up the illusion, ftp http, finger, etc). But some huge high performance sites use load-balancing webstar. Regardless, no mac has ever been rooted in history of the internet, except with a strange 3rd party tool in 1995.
8> MacOS source not available traditionally, except within apple, similar to Microsoft source only available to its summer interns and engineers, source is rare to MacOS. This makes it hard to look for programming mistakes, but I feel the restricted source access is not the main reasons the MacOS has never been remotely broken into and exploited.
Sure a fool can install freeware and shareware server tools and unsecure 3rd party addon tools for e-commerce, but a mac (MacOS 9) running WebStar is the most secure web server possible and webstar offers many services as is.
One 3rd party tool created the only known exploit backdoor in mac history and that was back in 1995 and is not, nor was, a widely used tool. I do not even know its name. From 1995 to 2002 not one macintosh web server on the internet has been broken into or defaced EVER. Other than that event or a rouge 3rd party CGI tool ages ago in 1995, no mac web server has ever been rooted,defaced,owned,scanned,exploited, etc. They few mistaken defacements recently attributed to Mac OS are actually Mac OS X (unix) events.
I think its quite amusing that there are over 200 or 300 known remote exploit vulnerabilities in RedHat over the years and not one MacOS 9.x or older remote exploit hack. There are even vulnerabilities a month ago in OpenBSD! Each month vulnerabilities in XP arise.
Not one remote exploit. And that includes Webstar and other web servers on the Mac.
A rare set of documentation tutorials and exercises on rewriting all buffer LINUX exploits from INTEL to PowerPC was published less than a year ago. The priceless hacker tutorials were by a linux fanatic : Christopher A Shepherd, 3036 Foxhill Circle #102, Apopka, FL 32703 and he wrote the tutorials in a context against BSD-Mach Mac OSX. but all of his unix methods will find little to exploit on a traditional MacOS server.
BTW this is NOT an add for webstar.. the recent versions of webstar sold for over the last year are insecure and cannot run on Mac OS 9.x or 8.x, and only run on the repeatedly exploited MacOS X.
--- too bad the linux community is so stubborn that they refuse to understand that the Mac has always been the most secure OS for servers.
BugTraq concurs! As does the WWW consortium. So you do not need a book to teach you how to pathetically try to secure a website, just use a Mac, as many colleges and large media sites do, and most commercial airlines for there in-house security.
Its a known incorect statement when you wrote "The best reference manual you can find on Windows 2000 internals is "Inside Windows 2000""
There are complete internals books with source code headers for the OS and even most of its hidden structures. The fact that the book is rare and MS fanboys do not know its name merely amuses me... it helps me write better exploits and root kits.
That book you cited is a MS apporved book and from MS, you are a fool if you think you get internals info from MS!!!!
Therefore you are blatantly trolling.
I will not do your homework for you but there are precious books out there on internals with misleading names for titles.
...of books called the C++ In-Depth Series. Very well-written, all by experts.
One of the series' rules is that the main body text of a book must be no more than 300 pages. Be clear, be concise, get to the point and shut up.
Most excellent books.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Why?
Big computer books are often filled with fluff, such as large illustrations, fancy typography or sidebars that don't add much meat.
What is really worse is that it takes a lot more work for a writer to explain a complex point concisely. I imagine it also takes more works for the editors to cut down on material that doesn't really add value to the book. My experience is that the big computer books are often poorly written.
Also, I don't have enough time to read all the technical books. It simply takes less time to read a compact, well-written book than a big, verbose tome. There's also the problem of fitting a bunch of big computer books on my limited bookshelf space.
I have observed that there seem to be an awful lot of big books for windows & web programming, and Java programming. The situation seems quite a bit better for C++ programming, with such slim books as Scott Meyers' "Effective C++".
There are long books which are worthwhile, but the ones that are both big and good are covering a topic that is very broad and detailed, for example Foley, Van Dam, Feiner and Hughes' "Computer Graphics".
My wife wanted to learn to use cascading stylesheets for her web design. The bookstore had two books, a small one by O'Reilly and a much larger one that seemed to cover the same material but had lots of fancy typography and illustrations and verbose text. In the end she chose the O'Reilly book, and after using it to design a website for some friends of ours she said she was very glad to have gotten the O'Reilly book.
Finally, I'd like to suggest that before you purchase a new technical book, check to see if there is a review of it at the Association of C and C++ Users book reviews section.
Request your free CD of my piano music.
I bought "Inside Windows 2000" a year and a half ago, and it's a good introduction for someone completely unfamiliar with the system, but is sorely lacking for critical details. It also is very politically-correct, in terms of advocating the Microsoft way.
The icing on the cake was the shrink-wrap EULA on the enclosed CD. After having spent a lot of time working with Linux, I found it positively insulting.
Request your free CD of my piano music.
Wow, nice rant! I don't know about your item-numbering system though - what happened to point 6? Must be all that "allergy medication" ;-)
Anyhoo, I'm sure what you say has some merit. If all you care about is security, and you've got the budget and available manpower of the US military.
From perspectives other than security an OS9 web serving solution strike me as expensive, not terribly scalable, and - from my admittedly limited experience of OS8 and 9 - possibly not all that stable either.
<cheap shot>Anyway, if it's so secure, how come you're whining that there's no section in the book for it?</cheap shot>
Ah well, maybe there just wasn't anything the authors could say that could possibly improve the security of the mighty Mac...
You know they call 'em fingers but I've never seen 'em fing. Oh, there they go.