The Evils of Default Security (tutorial)
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
Re: The Evils of Default Security (tutorial)
I was curious as to what your other positions on operating system security were, so I looked at some of your posts, and this is pretty well the best one it seems...
Quote:
Originally posted here by catch
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?)
Without facts to back you up? I find that somewhat amusing. Yes, let's not let little facts get in the way of our making our point shall we?
Quote:
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.
Oh, so what you mean to say is that the process of removing unneeded accounts, trimming down your user's access capabilities, jailing processes so that if they happen to be exploited system-wide access isn't guaranteed, and removing setuid binaries does nothing for actually securing a system? I want to make sure I get that right, since that's what you wrote and all. Wouldn't want to be confused about something like that.
Quote:
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.
You have evidently misunderstood the entire purpose of hardening your system. If you have some childish preconceived notion that hardening a system is done to prevent software vulnerabilities from happening, you possibly need to read a FAQ on the subject.
Quote:
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.
It does not fall short. It does exactly as advertised. That you are delusional and believe the hardening process is advertised as the be all and end all of security is not the responsibility of those who point out their OS is secure. You should seek some kind of understanding about the situation, rather than assuming you know what you're talking about when you actually evidently don't.
Quote:
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.
Yes, actually, I find it funny that you categorize the other two as being unimportant when they are indeed the actual flaws responsible for the Windows XP exploits/flaws as well as basically ALL of the IIS vulnerabilities. Since you are evidently also not a programmer (which leads me to wonder, who are you to speak of any authority on such matters), you also don't seem to get that the second option you list above, is indeed the same as the third and fourth you mention. Basic design flaws are still 'flawed source code'. I like how you're vague enough to fool people but can't be precise enough to show you know something.
Quote:
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]
And where is the proof of this? How can we not know that two instances of System B are more insecure because of something they are both doing (under the guise of homogenization) where the two instances of A are more secure because of their differing roles. If you look at it logically, it favours A actually:
Examplis Gratis:
System A1 runs a buggy webserver while System A2 runs only mail services.
System B1 and B2 run a buggy webservers.
Exploit comes out affecting said buggy webserver. 100% of System B machines will be affected, while only 50% of system A machines will be, due to diversity of services. So where is your logic that A (non-homogenous) will be worse?
Quote:
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.
Having played quite a bit of the intrusion game myself, I can unequivocally state you are wrong in your assumptions about attacker methodologies.
[..snippage of inane and utterly useless example..]
Quote:
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.[/b]
Indeed, that would be why those facts state otherwise (damn, knew those pesky things were going to come up once in a while). The truth is, 'secured by default', while definitely a marketing tool, is also a truth. Slackware and OpenBSD both have excellent security track records, since they don't enable anything by default. Secure by default and 'hardened' are not the same thing, which is yet another concept you seem to have failed to grasp. Secure by default is simply a way of securing the system from remote intrusion attempts by not having services starting up by default. Until OpenSSH, I believe both OpenBSD and Slackware had a perfect security record in terms of remote security.
I suppose given your opinion, everyone is MOST secure if they run out and install WinXP Pre-SP1, since any default security seems to be a waste.
Quote:
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.
Yes, it is a valid point to consider when comparing two systems. It sounds mostly to me like you just don't like being told you don't have a secure system by people who do. Indeed, that is your perogative to be cheesed off about it, but honestly, this diatribe of half-truths and outright falsehoods needed to be pointed out. The only reason you got any greenies for this is because evidently nobody was around to point out the utter flaws in this. Not only that, but why this is a tutorial I don't even know. It's an opinion essay, a very poorly researched one at that. Of course, there are those damn facts again eh? Why should you actually have to research something to believe you're right?
It saddens me to see that the level of technical expertise has fallen off so drastically that catch here is regarded as an 'expert' by some. He has a LOT of learning to do, and perhaps some decent discussion can be had after he lands a job (if) and gets bit by his idiotic practices.
