Slashdot Mirror
Web Security, Privacy and Commerce
My single biggest problem is typically that, while highly technical , I don't do security as a full time job. Reading the literature needed to become really expert just isn't in the cards. It's enough to keep up with Java, Python, C++ and grid computing stuff. Even though there is substantial overlap between grids and security, much of grid thought is separate from the implementations that are dealt with in this book. Besides, my group does large-scale data storage. We leave the security infrastructure to specialists.
Garfinkel's book is great for a guy like me. They take every subject from a level that is trivial to understand down to as much detail as you need. Even in areas that I understand pretty well, I found this book taught me new stuff. For example, in their section dealing with the history of browsers I had a handful of false memories corrected, despite having been around for longer than the web.
They've broken the book down into four sections, Web Technology, Privacy and Security for Users, Web Server Security and Security for Content Providers.
Web Technology
This section deals with the pieces that all the other sections depend on. Particularly interesting are the parts about the different kinds of cryptographic systems. They talk about symmetric and public key systems and message digest functions. These building blocks are then put to use in chapters on SSL/TLS and digital identification. This section also gives a brief history of the web and how it was assembled.
Privacy and Security for Users
These chapters are split between mobile code, Java, ActiveX, Flash and such and all other safety/privacy issues. In the chapter on backups, the authors tell an amusing story about backups that were being done by someone who hadn't been properly trained. She would start the job, then go and read a book. The backup would throw errors, but when the session timed out the errors were lost and the screen looked like a normal termination when she returned. This apparently went on for quite some time before being caught. So check your backups, kids!
This sections also has an interesting chapter on email privacy and a couple different services/methods for using encryption to secure your mail and, better yet, send email that cannot be read after a certain date.
Web Server Security
Every sysad in the business should make sure to read this section, which starts out talking about physical security (because if you don't have that the rest may not matter), and continues all the way down to deploying certificates.
Security for Content Providers
Finally, the book finishes up with a few chapters that are mostly about the legalities of running a site. This combines client authentication with privacy policies, digital payments and intellectual property into a good if less technical ending.
Overall
One interesting aspect of the authors' overall approach is that they are so platform neutral. I didn't expect this from a team that wrote books on Unix security, but they have chapters on ActiveX issues and it isn't dealt with in the flip manner that Unix people often use toward other OSes. Even their screen shots are in Windows. You definitely get the feeling these guys know there stuff from more than one perspective.
We happen to be talking a lot about public key infrastructures at work lately, and the chapters on digital certificates were quite handy in getting up to speed on the different issues. As with other sections, they deal not only with the bit twiddling involved but also with history and policy. The human issues. Very useful stuff about an area that not many think about and about which the existing writing is fairly opaque.
So, if you're needing to learn more about this subject I can't think of another book I would recommend before it. I've been motivated enough to write a review on it, and for most of us that's probably a ringing endorsement by itself!
You can purchase Web Security, Privacy and Commerce at Fatbrain.
..remove the words "Well, it's okay because that box is sitting behind our firewall" from everybodys lexicon.
;-)
The point was raised above about how out of date this book would be by the time it was released. I honestly don't believe that's as big of an issue as people seem to think, 99% of the battle with keeping our networks secure is just getting people to consider the issue in the first place. Any book I can throw at our apps developers that gets them even thinking about the broad issues is a good thing, because once the seed is planted, then they come over and ask us what we would reccomend as they're working on their apps. Over the past six months we've seen the 'Ooops, you mean that travel site with the form for people to put their CC number in should be SSL'd?' to almost daily informal meetings about what they're doing and how we can support them.
Our biggest nightmare has been the sysadmins. The NT sysadmin refuses to apply any patches, 'because then things break', and won't close a single port, 'if you want features, you have to leave things open'. Lots of guerilla midnight work going on behind that boy.
Our solaris sysadmin is no better, if you could take the words 'Well, back at Siemans..' out of his vocabulary, he wouldn't have anything to say. Yet, he's very good at the above mentioned meetings for arguing that we're too paranoid, 'Only a very skilled attacker could sniff passwords of our switched network,' and this after multiple times of showing him dsniff and ettercap in action, complete with grabbing his passwords several times. Once again, lots of midnight cowboy fixes behind the back.
There's a really good book out, Building Secure Software where he brings out some very good points. The best one being that security is put on networkings shoulders, when the real problem is that the developers don't build their applications with security in mind. Therefore, the strategy is to deny attackers access to the errors in the code, when the best practice would be to remove those errors in the first place. That and the quote about ecrypting information in transit is like a guy living on the sidewalk using an armored car to send his credit card information to a man living on the beach in a cardboard box is simply priceless.
Maybe instead of flaming an obviously standardized course known to produce a lot of windows admins, most of who know only what the book says and nothing more, you should flame those in charge of hiring at your company, for choosing someone from that course rather than someone with proven experience?
I'm all up for microsoft bashing in some situations. Bitching about security caused by poor admins is not one of them. Fix the admins, by not hiring the bad ones, and maybe they'll realize that if none of the brand new MCSE's can get a job, there's something wrong with the course.
Video for Online Dating Profiles
There are a few good reasons people do get an MCSE:
:-(
1. Pay is generally increased
2. Easy to do, if you know your stuff.
3. Resume fluff.
4. In a crappy economy, if you don't have one, the person who does, gets the job