On Tuesday 01 April 2003 09:47 am, Horatio B. Bogbindero wrote: > let them use it. it is my belief that security is more about implementation > and maintenance. the tools used just makes it either easier or harder to > implement and maintain. of course, i would not like to place my money in a > bank that uses insecure systems (even the preception of being insecure > could cause problems for the bank). > > besides i remember that a bank even used plain-text protocols for their > online transactions across the public internet!!! argh!!! so even if that > bank used the most secure network tools in the whole wide world, it would > still not make that banks network anymore secure.
No problem with that. Securing systems starts with software and ends with implementation. Windows, Linux, and other OSes must use that approach. Thus, security starts at the software level and ends in security implementation level. Here is the problem with Microsoft. The OS's vulnerability always starts at the software level. This complicates the task of securing systems. It's already tough implementing secure measures with Windows or Linux. Windows further compounds the problem with weak points in software. I'm not saying that FOSS has no vulnerabilities, but let me illustrate the points with a hypothetical example. Note that I somehow use the terms "patches" and "fixes" synonymously. Let's say a bank implements two redundant systems. System Penguin and System Redmond. The sysadmin finds that a cracker is probing his infrastructure for possible entry weak points, so he implements tougher security measures (like new and longer passwords, stricter permissions, etc...) for both systems. In both cases, the tougher security implementation strengthens both systems. System Penguin and System Redmond wins. The cracker, undaunted by the tougher security measures, probes further and finds software flaws in both System Penguin and System Redmond which allows him opportunity to bypass the security implementation level and compromise the system. The sysadmin hears about these vulnerabilities in Systems Penguin and Redmond. So he buckles down to work by isolating the affected systems, informs himself then searches for patches. He finds all patches for System Penguin within the span of 3 or 4 days at the most. He finds some patches for System Redmond. Sometimes he doesn't find any patches, because it will be incorporated 6-12 months later in a service pack, which the local distributor of the OS says the bank should pay for this service pack in the future. In this case, System Penguin wins because all patches are immediately available. He applies the patches to System Penguin. It's easy to apply patches to Penguin because software is discrete, which means that only the affected software are patched. The upgraded software will not break other apps in System Penguin due to the overall design of the OS. The end result is that System Penguin immediately becomes secure at the software level while System Redmond remains vulnerable. But wait, suppose he finds patches for System Redmond. He applies this patches and gets the system on its feet. He somehow feels a sense of accomplishment after patching the vulnerabilities. Several moments later, he finds that the patches break other stable functionalities in System Redmond. A user mentioned him about something going wrong in the system when previously it worked fine. The sysadmin tries to isolate the problem, and soon realizes that he can't. System Redmond is monolithic. The patch did fixed the vulnerability but created more pressing problems. In short, the patch didn't work. The next thing he does is reinstall System Redmond, hoping that it will never be probed again. And if it goes down again, he'll prepare in advance a hot-pluggable backup, or another redundant System Redmond B just in case. If he goes for installing System Redmond B, the bank incurs additional expenses (additional hardware, media, etc...) in preparing the backup system, plus the sysadmin effort is wasted. The cost of implementing roundabout measures compounds the problem. Notice that the troubles started from a patch that didn't work when it should work without breaking others. The real problem remains unfixed and the bank must wait for 6-12 months for the service pack. In the meantime, the sysadmin must unecessarily devise temporary measures to minimize the problem, relying on sheer luck the system will remain unprobed. System Redmond remains vulnerable. In short, when the security implementation level for both OS is the same, System Redmond loses because it has more unaudited weaknesses at the software level. Software level problems for System Redmond will not be a problem IF patches are available immediately, these patches work, and don't break things. But we are tired of patches that take too long. Sometimes the company that makes System Redmond will not admit there is a problem until the exploits gets worse and becomes a publicity problem for their company. We are tired of patches that don't work. Patches for System Penguin always work. When we can see through the innards of FOSS (including patches) and audit it, that's trust at the highest ideal comparable to the banking system's perception of trust. This trust spills over to customers, whether they understand the underlying technological platform or not. As Yoda might say, trust in banking earns market share, and market share leads to profits. System Penguin wins. Just thinking aloud with a light saber, mikol _ Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph To leave: send "unsubscribe" in the body to [EMAIL PROTECTED] Fully Searchable Archives With Friendly Web Interface at http://marc.free.net.ph To subscribe to the Linux Newbies' List: send "subscribe" in the body to [EMAIL PROTECTED]
