After a seven week leave from this site I figured I ought to try and come back with something useful and interesting to remind you all of how much you missed me.

A large percentage of this site and really all computer security forums focus on a single topic: "Which is better (more secure)?" where various people will throw out random biased opinions, unlisted options to show how smart they is, or perhaps even *gasp* relevant facts. Facts are good right? Well, to quote Homer Simpson, "Facts are meaningless. You can use facts to prove anything that's even remotely true. Facts shmacts." As a rule, Homer tends to be not too bright, but his words frequently carry a deeper truth thus he is so lovable. In this case it seems that just because something is a fact, doesn't mean it is a fact in a given situation...

Confused yet?

I speak of default configurations. I can't recall how many times I've come across "X is already hardened, so it is more secure." Operating system like OpenBSD and Windows 2003 both fine examples of tribute to this fallacy. The subject of this tutorial is to demonstrate to the reader that “more secure by default” actually results in a less secure real world system. (How is that for facts shmacts?)

----------------------------------------------------------------------------------------
Part 1: The inadequacies of “hardening”.

Hardening either before or after shipment typically includes but is not limited to the following actions:
  • Removing unnecessary packages/applications.
  • Removing unnecessary services.
  • Stronger default file permissions (removing suid/guid, adding sticky bits, etc)
  • Locking down administrative accounts. (Using wheel to limit su, preventing telnet access, etc.)
  • Utilizing an intrusion detection system. (Tripwire et al to monitor the system.)

Following this checklist you will have a very secure system right?

Nearly all computer attacks stem from the following six issues stack overflows, access to services, privilege and privileged accounts, networking resources, shared environments, and other bugs in applications and services. Considering this, it should be painfully clear how little hardening does for actually securing systems. Clearly different architectures and mechanisms are needed to deal with these issues as hardening alone is simply not viable.

The next broken BIND, thieving admin, or perhaps that one web application input that was accidentally not validated, just to name a few examples will suffer little resistance from your best hardening efforts.

I am sure many of you were already aware how this type of security falls short, but are probably still thinking that even the paltry security offered by hardening is better than nothing and for the vendor to offer such security by default not only makes your job easier but makes the system overall secure as few attacks happen against it.

----------------------------------------------------------------------------------------
Part 2: The benefits of homogenization. (Important points but a non-definitive argument.)

Nearly all exploits all into one of two categories:
[list=1][*]Configuration error.[*]Otherwise correct configuration but inadequate to provide protection against flawed source code.[/list=1]
The Apache.org root via FTP/Apache/MySQL configuration errors is a fine example of the former while the IIS Unicode attacks of the latter. While it is true that two additional types of exploit exist (source error indefensible by a different configuration and design flaws that have no source issues and cannot be fixed via admin configuration) these have not be included as they make up a very small percentage of real world attacks and because they have nothing to do with the subject of this tutorial.

Let us compare two systems now, one shipped in a soft state (systemA) and one shipped in a hardened state (systemB).
[list=1][*]Any two instances of systemB are likely to exist in the same state, as implementation/administrative intervention is less likely since a “secure” system was purchased.[*]Any two instances of systemA are likely to exist in different states, as post-purchase configuration is needed to bring the system into a secure state.[*]Any single instance of systemA is more likely to exist in an insecure state than any single instance of systemB.[/list=1]
This means, that since systemA is more likely to be insecure, valid exploits are more likely to exist. It also means that an instance of systemA, which has been configured to an equal state of security to systemB, is actually less likely to be effected by exploits than systemB is. Consequently the likelihood of systemB being vulnerable to random threats is greater than systemA existing in the same state. SystemA is also likely to be less vulnerable against specific threats since the exact configuration is less likely to be known by the attacker. Your odds of being the victim of packaged attacks are reduced without patches and the odds of you not seeing a 0-day attack coming are also reduced as a greater likelihood of an attacker error exists.

It is true that a systemB implementer/administrator could alter systemB’s configuration making it less predictable, but this would not only remove any advantages of having a secure by default system it would also play into bigger issues identified in section three.

----------------------------------------------------------------------------------------
Part 3: The costs and consequences of knowledge.

Consider two sand castles, the first already built the second a kit containing your bag of sand, various molds, and a detailed instruction manual. Using the kit you are able to make a sand castle (castleA) exactly like the one already built (castleB), and you do so. Now there are two identical sand castles on the table in front of you.

Depending on how exact you were in the construction of castleA, it is possible to know essentially everything about it. How many grains of sand in the left tower, the exact volume of the moat, if any additional measures are needed so that a base width of X can support a height of Y, etc, etc. If you add an extra doorway into the wall of castleA and you track what exactly you remove, you will know exactly what remains and have a better understanding of exactly how the remains are structured. Less chance for error exists and less requirement for auditing.

This example of sand castles may seem silly, but when compared to information system security it becomes highly valid. If for some reason you need to change the security of systemA, this will be very easy, especially from the default state. An error become obvious as you add security, if something no longer functions that was needed to function, undo the last step. When starting with a system secure by default and functionality needs to be added, errors will not present themselves without an additional security review. Additionally the implementer needs to know far more about the system to make changes. This can be easy with an old system, but to completely learn the number of grains in a system or patch just released… it gets impractical. (I’m not talking source I’m talking roles.) Critical elements may be (and in practice frequently are) inadvertently removed while trying to increase functionality.

In any controlled system it is a simpler task to calculate the effects of the addition of an element rather than a subtraction of one.

----------------------------------------------------------------------------------------
Part 4: What it all means.

Systems secure by default are little more than a marketing ploy, that prey upon users lack of understanding about the actual mechanisms and architectures that go into secure computing. These vendors feel that they will make more sales by selling a product that seems more secure than one that actually is more secure. (Unless you are like OpenBSD and scare all your clients away with your pompousness.) Odds are they are probably right, but that doesn’t mean it is a valid point to consider when comparing two systems.

If you start with something insecure but highly functional, so long as it comes with the tools to lock it down you’ll be ahead in security assurances, costs, time, and the skill level needed by your implementer.

catch