Book Review: Hurricane Fever by Tobias S. Buckell

Update 7/17 16:21 to add disclosure: I received my ARC copy of this book via a reviewer giveaway from the author’s blog. I had to request the copy.

Note: this review is spoiler-free.

Tobias Buckell writes very smart people-centric speculative fiction. When I was reading the ARC of his latest novel Hurricane Fever, I realized he has quietly become one of my five favorite authors.

Hurricane Fever

One of the reasons is how he writes in a style I’ll just have to call “Flow” for lack of a more precise term. From the non-typical (and welcome) way Buckell deals with writing dialect to his pacing, his stories move smoothly from introduction to crises to resolution. You cover a lot of ground, but it doesn’t feel like it, much like a ramble through the countryside. Hurricane Rising is no exception. Even as the tension and the stakes crank up, the book is a relaxing read. Even if you haven’t read the first book in the series, Arctic Rising, you should be able to drop right in without feeling like you’ve missed anything. (I can’t promise that you will still feel that way when you get to the end; if you feel the need to run right out to the library or to a bookstore, or at least make a big order on Amazon, you’re in good company.)

Another reason is how his stories deal with big ideas of world-shaping significance. Hurricane Rising is a near-future espionage thriller that rivals the scope of a Bond story, with a world-threatening plan that would make Fleming green with envy. In most books, the writer would try to give us hints that Something Big was coming; Buckell makes us care about the people and reels us in from there. The protagonist, Prudence “Roo” Jones, is a retired Caribbean intelligence agent who is just trying to raise the nephew who is all the family he has left. Roo is drawn out of his life onboard a catamaran into the unfolding geopolitical events because he is driven by bonds of family and friendship, not for the sake of power or adrenaline or some abstract duty.

Tobias Buckell writes very smart SF

Probably the biggest reason, though, is that Buckell’s version of smart isn’t intimidating like so much SF can be if you don’t know as much as the author. Rather, his writing is inviting and comfortable. If you know as little about the Caribbean islands as I do, this may be the book that will lead you to your atlas or tablet so you can look up the geography Buckell so lovingly introduces us to. Roo lives just around the corner of tomorrow where the consequences of our bad decisions have come home to roost; climate change has remapped our coastlines, tweaked the balances of power and resources, and altered the patterns of weather. There is a lot of thoughtful worldbuilding that has gone on behind the scenes, but Buckell is comfortable enough in his skill as a storyteller to let it slip in hints and dashes – a master chef deftly and subtly spicing the meal he is preparing. There are no infodumps, no expository lumps, and no detours through backwaters whose only purpose is to show off a feature of the world that would otherwise lay untouched by the plot. I felt like Buckell had made a pact with me: he would stay on task of telling a compelling story, and I would bring my reader A-game and imagination to come play for a while.

We in the Seattle area will host Buckell at University Bookstore on July 28th, one of just five appearances in the Hurricane Rising West Coast Book Tour. I’ll be taking the opportunity to fill in some of the gaps in my library. Hope to see you there!

The iPhone Wars, Day 121

120 days later and I figured it was time for an update on the war.

First: I still hate this thing.

Somewhere along the way with one of the iOS updates, the battery life started going to crap, even when I’m barely using the device. When I use it as a personal hotspot, I can practically watch the battery meter race to zero.

I’ve nailed down what it is about the email client that I don’t like, and it’s the same thing I don’t like about many of the apps: the user interfaces are inconsistent and cramped. Navigating my way through a breadcrumb trail that is up near (but not quite) up at the top just feels clunky. This is where contrast with Windows Phone really, really hurts the iPhone in my experience; the Metro (I know, we’re not supposed to call it that anymore, but they can bite me) user interface principles are clean and clear. Trying to figure out simple tasks like how to get the iPhone to actually resync is more complex than necessary. Having the “new message” icon down on the bottom when the navigation is up top is stupid.

The one thing that impresses me consistently is even though the screen is small, the on-screen keyboard is really good at figuring out which letter I am trying to hit. On my Windows Phone I mistype things all the time. This rarely happens on the iPhone. Even though the on-screen keys are much smaller, the iPhone typing precision is much higher. Microsoft, take note – I’m tired of what feels like pressing on one key only to have another key grab the focus.

Even the few custom apps I do use on this iPhone fail to impress. Thanks to a lack of consistent design language, learning one doesn’t help me with the rest, and I have discovered that iPhone developers are just as bad as Windows Phone developers when it comes to inexplicable gaps in functionality.

I guess no one knows how to write good mobile software yet.

The iPhone Wars, Day 1

Part of the fun of settling into a new job is the new tools. In this trade, that’s the laptop and the cell phone. Now, I already have a perfectly good laptop and cell phone, so I probably could have just gone on using those, but where so much of what I do is from home, I find it important to have a clear break between personal business and work. Having separate devices helps me define that line.

My current cell phone is a Nokia Lumia 1020 (Windows Phone 8), which I definitely enjoy. I haven’t had a good chance to take the camera for a full spin, but I’m looking forward to it. I’ve had a lot of PDAs and smart phones in my time: Palm Pilot, Handspring Visor, Windows Mobile, BlackBerry, Windows Phone 7, even an Android. The one I’ve never had, though, is an iPhone.

And it’s not that I hate Apple. My favorite past laptop was my MacBook Pro (Apple has ruined me for any other touchpad). Granted, I’m that weird bastard who loaded Vista SP1 into Boot Camp and hardly ever booted back into Mac OS X again, but ever since then I’ve usually had a spare Apple computer around the house, if only for Exchange interop testing. OS X is a good operating system, but it’s not my favorite, so my main device is always a Windows machine. My current favorite is my Surface Pro.

In all of that, though, I’ve never had an iOS device. Never an iPhone, never an iPad. Yesterday, that all changed.

I needed a business smart phone that runs a specific application, one that hasn’t yet been ported to Windows Phone. I’ve long been an advocate that “apps matter first; pick your OS and platform after you know what apps you need.” Here was my opportunity not to be a shining hypocrite! After discussion with Jeremy, I finally settled on a iPhone 5, as Android was going to be less suitable for reasons too boring to go into.

So now I have an iPhone, and I have just one question for you iPhone-lovers of the world: You really like this thing? Honest to goodness, no one is putting a gun to your head?

I can’t stand this bloody thing! First, it’s too damn small! I mean, yes, I like my smart phones somewhat large, but I have big hands and I have pockets. The iPhone 5 is a slim, flat little black carbon slab with no heft. I’ve taken to calling it the CSD – the Carbon Suppository of Death. Now, if it were just the form factor, I could get used to it, but there’s so much more that I can’t stand:

  • I didn’t realize how much I love the Windows Phone customizable menu until I wasn’t using it. I forget who once called the iPhone (and Android) menu “Program Manager Reborn” but it’s totally apt. Plus, all the chrome (even in iOS 7) just feels cluttered and junky now.
  • Speaking of cluttered, Apple sometimes takes the minimalist thing too far. One button is not enough. This, I think, Windows Phone nails perfectly. Android’s four buttons feel extraneous, but Apple’s “let there be one” approach feels like dogma that won’t bow to practicality.
  • The last time I used an iPod, it was still black & white. I can’t stand iTunes as a music manager, and I don’t like the device-side interface – so I won’t be putting any music on the CSD. No advantage there.
  • Likewise, you think I’m going to dink around with the camera on the CSD when I have the glorious Lumia camera to use? Get real, human.
  • The on-screen keyboard sucks. Part of this is because the device is so much smaller, but part of it is that Apple doesn’t seem to understand little touches that improve usability. On Windows and Android, when you touch the shift key, the case of the letters on the keys changes correspondingly; Apple is all, “LOL…NOPE!”
  • Even the Mail client irritates me, even though I haven’t managed to put my finger on exactly why yet.

So is there anything I like about the device? Sure! I’m not a total curmudgeon:

  • Build quality looks impressive. If the CSD wasn’t as flimsy as a communion wafer, I would be blown away by the feel of the device. It’s got good clean lines and understated elegance, like that suit from the expensive Saville Row tailors.
  • Power usage. The CSD goes through battery very slowly. Now part of that is because I’m not using it, but Apple has had time to optimize their game, and they do it very well indeed.
  • The simple little physical switch to put the CSD into silent mode. This is exactly the kind of physical control EVERY smart phone should have, just like every laptop should have a physical switch to disable the radios (not just a hotkey combination).

This is where I’m at, with a fistful of suck. Even an Android phone would be better than this. I’ve got no-one to blame but myself, and it’s not going to get any better. So look forward to more of these posts from time to time as I find yet another aspect of the CSD that drives me crazy.

“But Devin,” I hear some of you Apple-pandering do-gooders say, “You’re just not used to it yet. Give it time. You’ll grow to love it.”


Review: Cooking for Geeks (O’Reilly)

Edit 1/1/2013: (Belatedly) updated the author’s website per his request.

Writing books is a ton of work. Making them appealing is even more so, especially when your audience is geeks. You have to know your stuff, you have to present it well, and it doesn’t hurt if you can make it entertaining. In the technical field, I think O’Reilly is the one publisher that hits this bar more consistently than any other publisher. Getting to co-write my first book for them was a great experience; if they ever came asking me to work on another book for them, I would seriously think about it (more importantly, my wife wouldn’t automatically say no).

Back at the end 0f August, I had the opportunity, thanks to the @OReillyMedia twitter feed, to get my hands on a review copy of Cooking for Geeks (CfG) in e-book format. As part of the review agreement, I was supposed to:

  • Select a recipe from the book,
  • Prepare it,
  • Photograph it,
  • Write a review and post it,
  • Post the photograph on the O’Reilly Facebook page,
  • and all by September 6th.

Oops. Obviously, I’ve missed the precise timing here, but a bit belated, here’s the review I owe.

Why this cooking book?

There’s a lot of information on cooking out there. Stephanie has a metric ton of cookbooks and collected recipes in our house, and there are large chunks of old-growth forest bound up in the various cookbooks you can find in various stores. Thanks to the celebrity chef craze on TV, cooking (never an unpopular subject) has grown leaps and bounds beyond the good old Betty Crocker Cookbook that many of us grew up with[1]. Popular TV chefs now write and sell cookbooks on just about any specialty and niche you can imagine. I’ve even indulged in the recipe fetish myself once or twice, most noticeably to snag and perfect my favorite dish, the Cheesecake Factory’s Spicy Cashew Chicken dish.

What caught my attention (other than this being an O’Reilly book) about CfG was that my household has been slowly and steadily moving into the exciting world of food allergens. We recently flung ourselves off the cliffs of insanity this summer when blood tests revealed that Steph and Treanna tested positive for gluten antibodies. Add that to the existing dairy-free regime, and it was clear that menu planning at Chez Ganger had just started a new, exciting, but potentially very limited and boring chapter.

We’ve got a lot of friend who are gluten-free, dairy-free, vegetarian, vegan, some other regime, or even combinations of the above, so Steph’s no stranger to the issues involved. What is doable as an occasional thing, though, can become overwhelming when it’s a sudden lifestyle change that comes hard on the heels of a long, exhausting summer – just in time for the new school year. Understandably, Steph was struggling to cope – and we weren’t exactly the most helpful crew she could hope for.

After a few weeks of the same basic dishes being served over and over again, I was ready for any lifesaver that I could find. That’s when the fateful tweet caught my eye. After a few rounds of back and forth e-mail, I discovered that CfG included a chapter on cooking to accommodate allergens. The rest, as they say, is fate.

Torturing Chickens For Fun and Noms

Although I could go into great detail about the recipe my family ended up selecting – butterflied roasted chicken – my wife has already done so. Like a good writer, I will steal her efforts link to her blog post instead. She even took pictures! Go, read and salivate!

Back already?

Under the Cover

CfG is written by Jeff Potter, whose geek credentials appear to be genuine. The book has a fantastic companion site, which is essentially a link fest to the related blog and Twitter stream (as well as to the various places you can go on the Internet to purchase a copy of the book).

My lovely wife handled the “cooking” and “presentation” parts well, so I’m going to move on to our thoughts about the book itself:

  • Content. If you want a book that explores the science and the art behind cooking, this is your book. It’s not a college textbook; it’s a great middle school or high school-level overview of the science of cooking that seems more interested in sharing Jeff’s love of cooking with you rather than creating cooking’s equivalent of the CCIE. Jeff writes with a very informal personable voice and isn’t afraid to show off his mastery of the physics behind good and bad dishes, sharing them in a way that’s part Bill Nye the Science Guy and part Ferris Bueller. I have never before laughed while reading a book on cooking. However, if you’re expecting a cookbook, check your expectations at the door. If this book has a weakness, it’s that talking about all this food will make you want a lot of recipes to try out, and I was surprised by how relatively few recipes there actually are. What is there provides an interesting cross-section across different types of dishes and ingredients, but it’s not a comprehensive reference guide. This is not “Cooking in a Nutshell” or cooking’s Camel Book; it is instead a not-to-scale map of the CfG theme park. If you find something that entrances you, you should be able to walk away with enough exposure to be able to knowledgeably pick out some other more detailed work for given area. CfG is the culinary equivalent of Jerome K. Jerome’s immortal Three Men in a Boat (To Say Nothing of the Dog); you’re going to get a fantastic lazy summer day punt trip down the river of Jeff’s epicurean experiences.
  • Format. We used the PDF format (like all of O’Reilly’s e-books, unencumbered by DRM). Steph already made a comment about how useful she found the e-book format. With a sturdy tablet, I think an e-book cookbook would be great in the kitchen, especially if there were some great application that could handle browsing and organizing recipes from multiple sources. As I already said, though, this book is not a cookbook and I’d probably just make a quick copy of (or retype) the recipes I was interested in so that I didn’t have to use the physical book in the kitchen. Having said that, though, we’re going to purchase a physical copy of the book to facilitate quick browsing. If you’ve already made the switch to casual e-reading (we have not yet), you probably won’t have this same issue.
  • Organization. Whether you like the book’s organization will depend on what you wanted out of it. If you wanted cooking’s Camel Book, you will find the book to be dismayingly unorganized. The structure of the book (and the recipes within) are based around the physics of cooking. Here, Jeff reveals himself to be a Lego Master of building blocks – you will find yourself introduced to one scientific concept after another, and each chapter will build on that knowledge by concentrating on a particular theme or technique rather than on a specific type of food or course. It really will help you to think of it as a novel (a romance, actually, between Jeff and food) and read the book from cover to cover rather than jump around in typical O’Reilly reference format. This is passion, not profession; calling, not career.
  • Utility. I’m pretty much a dunce when it comes to cooking, so I found this book to be extremely useful. I hate following the typical magical thinking approach to cooking: put ingredient A into slot B and pull on tab C for 30 minutes until you screw it all up because you didn’t know that your masterpiece was afraid of loud noises. I want to know why I’m putting nasty old cream of tartar into my mixing bowl; what purpose does it serve? How can I usefully strike out into the scary wilderness of trying to adapt existing favorite recipes to a gluten-free, dairy-free existence? CfG doesn’t answer all my questions, but it answers a hell of a lot more of them than any other cooking book I’ve picked up. It didn’t talk down to me, but it didn’t assume I was already a lifelong member of the Secret and Worshipful Order of Basters, Bakers, and Broilers. What it didn’t do, though, is give me a large number of variations on a theme to go and try. At times the recipe selection – while ecletic and representative – felt somewhat sparse and even unrelated to what was being talked about in the main text. It seemed like someone on the team had written a badly behaved random recipe widget[2] to insert a recipe every so often. I would love, in the second edition, to see a little bit more connection between the theory and the practice, even though I recognize this isn’t a textbook.

We found our payoff in the chapter on cooking around allergens. Of all the chapters, this is the one that most felt like a reference work — a concise but thorough reference work. Jeff explains why (for example) taking gluten out of a recipe and merely substituting some non-gluten flour is probably not going to produce edible results, and then explains some of the common approaches for dealing with the problem. He’s trusting us, the readers, to be able and willing to do some experimentation and find our own way without having a GPS to lead us by the nose. While it’s initially tempting to have the comfort of specific substitution steps, in the end, CfG will help you know how to make substitutions on your own and quickly dial in to an acceptable solution rather than sit around waiting for someone to write the HOWTO.

In the end, Jeff’s approach is empowerment. We liked it a lot; thank you, Jeff and O’Reilly!

[1] Not only did I grow up with one and spend a lot of time browsing it, Steph has one. I’ll have you know, however, that I’ve only flipped through it once for auld lang syne.

[2] Probably written in Ruby or PHP.

Review: Protect Your Windows Network by Jesper M. Johansson and Steve Riley (Addison-Wesley)


Title: Protect Your Windows Network
Authors: Jesper M. Johansson and Steve Riley
Publisher: Addison-Wesley
ISBN: 0-321-33643-7
Price: $49.99 SRP (578 pages with CD)

Let me cut to the chase: if you’re a Windows admin and you are at all worried about security, get this book. Now.

Okay, having said that let me tell you about the book. Here’s the back blurb:

In this book, two senior members of Microsoft’s Security Business and Technology Unit present a complete “Defense in Depth” model for protecting any Windows network — no matter how large or complex. Drawing on their work with hundreds of enterprise customers, they systematically address all the three elements of a successful security program: people, processes, and technology.

I’ve been doing a lot of professional security work over the years, much of it with Windows. I tend to treat new security books with a big grain of salt, because there are far too many well-meaning people out there giving advice ranging from mildly wrong to actively harmful. Now that I’ve written a book of my own, I have a fair idea of what is involved and how easy it is for authors to slip technical howlers past their hard-working editors (who aren’t usually experts in the topic). Just because something is written down in a book doesn’t mean I automatically trust it; unfortunately, too many people do place their faith in the Holy Grail of the printed word. On the other hand, I’ve not only seen Jesper and Steve speak before, I’ve had the opportunity to work with them on past projects, so I have a reasonable amount of faith that they actually know what they’re talking about. (If you haven’t had the pleasure of hearing them speak, go find the events they’re at and sign up. Trust me.) As a result, I was pretty sure this book was going to rock on toast and give me a few good hard nuggets to think about.

It didn’t.

This book completely threw many of my security assumptions out the window. More than once, I was reading the book shaking my head, saying “No, no, that’s not right!” as the authors made hamburgers out of yet another security sacred cow. After giving myself time to think about it from a real-world point of view, though, I almost always came away agreeing with them. At other times, I’d be pumping my fist in the air, ecstatic that somebody else Got It and was able to put it as eloquently as I’d just read. I don’t normally read technical books cover to cover; not only did I read this one straight through, I went back for a second pass with a bunch of sticky flags. My copy now looks like it was in a Twister factory explosion. My wife got to hear a fair amount of the book too; she’d come in asking why I was laughing and I’d have to read the offending portion to her.

The book comes with a CD; it’s not got a lot on it, but the scripts that are there are very useful indeed. There’s also an accompanying website,, which contains errata and downloadable copies of the scripts and files on the CD.

Here, along with the outline of chapters, is a sampling of the many gems I found in this book:

  • Chapter 1, Introduction to Network Protection:
    • Page 4 and 17: the book is not about building a secure network, since network security as an end state is impossible. You don’t want to be completely secure; you just want to be secure enough.
    • Page 8: the four types of attacks (automated or manual vs. passive or active).
    • Page 20: defense in depth does not mean piling on the tweaks. It includes people, policies, and processes as well as technical resources. Before you make a change, you should know exactly what problem it mitigates or blocks and that problem needs to be significant enough of a risk to warrant the reduced functionality.
  • Chapter 2, Anatomy of a Hack — The Rise and Fall of Your Network: the whole chapter. This is a great walkthrough, with real command lines and data, showing one way that a nominally secure network is successfully attacked. A standout point is made on pp. 73-76: your only real option for getting an attacker out of the network is draining the network and rebuilding. There’s a woefully impressive list of “You cannots” that directly addresses common mistakes people make after detecting an attack, such as trying to clean a system instead of rebuild it.
  • Chapter 3, Rule Number 1: Patch Your Systems
    • Page 80: “Note: If you think patching makes a system unstable, try getting yourself hacked. That tends to be even more destabilizing!”
    • Page 83: Patch Management is Risk Management. (Oddly enough, so is security.)
    • Page 101: how to create slipstreamed installations of Windows. They even include a nifty script to help make this process easier.
  • Chapter 4, Developing Security Policies
    • Page 113: “Without a security policy, you cannot have an effective network protection strategy. The security policy is what tells you what threats you are facing, which ones you are willing to accept, and which ones you want to mitigate.”
    • Page 127: how to set up a system sensitivity classification policy. Not all servers are created equal; you need to know which systems are most critical and need the most protection.
  • Chapter 5, Educating Those Pesky Users:
    • A lot of this chapter talks about social engineering and gives specific examples of how to find the information you need. It also tells you how to inform your users of the threat and how to design your policies so that people’s natural impulse to help acts to reinforce your security instead of circumvent it.
    • Page 153 gives the ultimate secret for getting information to your organization and ensuring they’ll remember it later: throw a party, give them beer and pizza, then tell them what you need to tell them.
  • Chapter 6, If You Do Not Have Physical Security, You Do Not Have Security:
    • Page 160 replaces the traditional, incomplete 7-layer OSI network model with the real deal: Layer 0 (Physical–Meatspace), Layer 1 (Physical–Interconnect), Layer 2 (Data Link), Layer 3 (Network), Layer 4 (Transport), Layer 5 (Session), Layer 6 (Presentation), Layer 7 (Application), Layer 8 (People), Layer 9 (Management), Layer 10 (Politics), Layer 11 (Religion). Don’t laugh — it’s true.
    • Page 171: don’t waste time trying to disable USB drives. The very next page gives a long list of ways people can circumvent your restrictions and get data out of your computers and organization if they really want to.
    • Page 175: the Encrypting File System (EFS) is good for laptops.
  • Chapter 7, Protecting Your Perimeter:
    • Page 183: Perimeter? What perimeter? You can’t rely on a strong perimeter/DMZ model anymore.
    • Page 191: the five rules you need on your border router (block all inbound traffic claiming to be from your internal network, block all outbound traffic claiming to be from some network other than your internal network, block all traffic to or from private network ranges, block all source-routed traffic, and block all fragments). Drop these packets before they ever get to your firewalls.
    • Pages 192-198: picking the right firewall (packet-filtering vs. application filtering, software vs. appliance, one brand vs. multiple)
    • Page 208: “Unless you have a need to inspect all traffic between VPN clients and the internal network, the best place to locate your VPN server is alongside your firewall. Because RRAS can protect itself and because you probably aren’t doing internal inspection in your network, placing your VPN server alongside your firewall is logical and helps keep your network design simpler.” (Anybody’s brain breaking yet?)
  • Chapter 8, Security Dependencies:
    • Page 225: “Note: Domain administrative accounts are for logging on to domain controllers and other systems that are as sensitive and as well protected as domain controllers. They must never be used on any other system.”
    • Page 225 again: The problem with writing passwords down isn’t that they’re written down. It’s that the written copies are not adequately protected. Recording your passwords is a good step and increases your security — as long as they are protected.
    • Page 227: Using the Passgen tool (included with the book) to secure accounts by giving them long, random, complex passwords without telling even you what they are.
  • Chapter 9, Network Threat Modeling: again, this whole chapter is worth the price of the book. One particularly nice sidebar on page 243 categorizes the six types of threats: STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege). Table 9-1 on pp.258-263 gives you a detailed list of traffic and ports used by Windows domain controllers.
  • Chapter 10, Preventing Rogue Access Inside the Network:
    • Big grins on page 267: “It should be obvious by now that if a bad guy is inside your network, you have serious problems. However, all hope is not lost. After all, bad guys connect to your network all the time, although we usually call them users.”
    • Pages 267-269: why network sniffing isn’t as big of a threat as security admins think it is. (Risk management redux.)
    • Page 272: how to use 802.1x to protect your network (and why, on page 275, it won’t really protect your wired networks). Use it along with WPA for your wireless networks and they’ll be stronger than your wired networks.
    • Pages 283-296: how to use Windows IPsec policies to stop worms, protect your network servers from rogue clients, and implement domain isolation (Domain isolation = devices cannot communicate with your domain resources unless they are domain-joined and have the proper IPsec policies).
  • Chapter 11, Passwords and Other Authentication Mechanisms — The Last Line of Defense: again, this whole chapter is good because it punctures a lot of myths about passwords (No, passwords are really a bad way to authenticate; you should be using passphrases, which are stronger yet easier to remember; better yet, use other forms of authentication). It includes a good discussion of why taking extraordinary measures to come up with uncrackable passwords may often be wasted effort — you need to be protecting your password hashes, which are gold.
  • Chapter 12, Server and Client Hardening:
    • Pages 355-364: ten security configuration myths. These points are good; many are counter-intuitive (security guides don’t really make your system secure? WHOA!)
    • Pages 365-377: the top ten server tweaks you need to make.
    • Pages 377-385: the top ten client tweaks you need to make.
    • Pages 385-387: tweaks you should not make.
  • Chapter 13, Protecting User Applications:
    • Page 398: make your applications run under nonadmin accounts (least user access, or LUA).
    • Page 400: if you aren’t using it, don’t install it.
    • Page 402: how to lock down the browser (IE, of course).
  • Chapter 14, Protecting Services and Server Applications:
    • Pages 415-416: “You will constantly run into statements like ‘that is not supported’ and ‘we have never tested that.’ Those statements are very important, but they do not mean you cannot do something. They just mean you may be on your own doing it.”
    • Page 417: Rule 1: All Samples Are Evil. They provide easy attack routes. (Sample IIS apps, anyone?)
    • Page 418: how to reduce your attack surface.
    • Pages 421-445 give a clear and concise description of how you go about analyzing services to find out what privileges they really need (as opposed to the ones they tell you they need), as well as how to harden SQL Server and IIS. Get rid of services running as administrative accounts!
  • Chapter 15, Security for Small Businesses: this chapter is a good discussion of how to use the same principles in smaller businesses, where Small Business Server may be deployed. “Regardless of size, all networks face pretty much the same threats.”
  • Chapter 16, Evaluating Application Security:
    • Page 469: how to baseline your system.
    • Pages 471-487: what sorts of issues to watch out for.
  • Chapter 17, Data Protection Mechanisms: it isn’t enough to secure your network, servers, and clients. Now you have to secure the data — how to set up effective ACLs, access control best practices, and why you might want to look at rights management systems.
  • Appendix A, How to Get Your Network hacked in 10 Easy Steps
  • Appendix B, Script To Revoke SQL Server PUBLIC Permissions
  • Appendix C, HOSTS file to Block Spyware (this has since been replaced by the errata and may not be in your printing of the book.
  • Appendix D, Password Generator Tool
  • Appendix E, 10 Immutable Laws of Security
  • A CD containing:
    • The HOSTS file from Appendix C (again, this has since been replaced).
    • The password generator (PassGen) in Appendix D. The CD version is 1.0; the website version is 1.1 and can generate passwords up to 256 characters long.
    • The SQL hardening script in Appendix B.
    • The slipstreaming script in Chapter 3.


Some of the best content of the book isn’t contained in the book — it’s on the website in the Listening Room. Here, you can find recorded versions of talks by Jesper and Steve. You’ll find their talks cover a lot of the same ground the book does, but they are both dynamic speakers; hearing the material reinforces what you’ve just read.

So, is this book for you? Let me answer that with another question: Are you tired of being a prisoner to security bulletins, patches, conflicting (and confusing) security guidance, and vendor claims?

If you want to learn how to actually analyze your systems and network, asses the threats you face, and do more than follow step-by-step “hardening guides” that inevitably break the CEO’s favorite applications, then you need to get this book. It won’t give you false warm fuzzies; it won’t hold your hand and do your thinking for you, because the reality of security is that everybody’s system is different. You can’t produce cookie-cutter protection for a moving target; there is no substitute for digging in and learning the techniques Jesper and Steve show you here. If you put the work in, though, I can promise you will have a much better understanding of what it takes to keep your systems and network secure, and how to adapt as the threat landscape changes.

If you want to keep plodding on, performing security by rote, following checklists, then don’t read this book. It will make you question your assumptions and might even lead to thinking. And the bad guys in your network don’t want that.

[Edited 12/9 to fix typos and clarify wording in a few places.]