In defence of the article, it has some good ideas. On the other hand it completely overlooks what people should be doing to secure their systems, regardless of

In defence of the article, it has some good ideas. On the other hand it completely overlooks what people should be doing to secure their systems, regardless of OS. People should look at the role of the system and the information assets contained therein, then determine (if possible) what types of attack and attacker might be able to get in, and how - that tells you what you need to do. If you're not able to do the latter, but can do the former then you're still able to secure your system. A classic example would be a firewall. Your firewall contains no information assets beyond your ruleset. Your firewall however can be used to open up internal access to your network. We can then say, "We believe our attackers will mainly come from the outside". How will they get in? We don't know. What can we do to stop them from accessing the firewall? Put a rule in to drop all traffic with a destination of the firewall's external IP address or network interface. Providing your routing's set up correctly, you've now put in an appropriate countermeasure. Rinse, repeat for all of your Internet-facing assets, hosts, services and applications. It sounds a lot, but it gets quicker the more you do it. Most unlaunched startups with relatively uncomplex setups could do this in a day. Here's another example. Our Apache server is accessible from the Internet. Who can access it? Everyone. Does everyone need to access it? Yes - we're using it to host our application. Who is going to attack this? We don't know, could be someone skilled, could be someone not skilled. How will they get in? An Apache exploit, an Apache misconfiguration, something further up the stack (like our app or PHP). What do we do about it? We maintain Apache versions (to address the Apache exploit issue as best as we can). We make sure all unnecessary Apache modules are disabled and that our Apache setup is as minimal as possible, then look at the directives on the Apache docs and change the settings to be as effective as possible (without breaking our app of course) - this addresses the misconfiguration issue. If we have to switch something on we now know the effect of that and if concerned can ask HN, monitor it or both. As for something further up the stack, let's repeat the process on the way up until we're comfortable with what we have. If you're writing down your reasoning and your results along the way this will help you get up to speed - it also means you can write your own hardening guide, or even integrate it into fabric scripts to save time in the future. You'll also massively increase your understanding of the software you're using in the process, so it's definitely worth doing.