Interview with Brian Hatch, author of
Date: October 15, 2003Source: Computer Crime Research Center
... their own systems, testing or compromising their own security, to understand things more intimately.
Overall, HLEv2 probably took nine months for James and I to write. That would have been shortened to 6 months or so had we been able to write in a useful format, such as LaTeX, which would also have allowed us to use CVS more fully between we authors and the editors.
The talk in all the trade rags and media is that there's an increased focus on security throughout the business world. Unfortunately, from what I've seen recently, it seems that the focus is on "hoping no one realizes our company is only giving it lip service." While some businesses are taking great steps, most are putting security on the back burner until the economy turns around. (I'm speaking from a US-centric position here because that's where I am. Much of the world is taking better steps toward security than the US.)
The mentality is that security is a second tier, a nice added bonus, when times are going well and you can afford to 'waste money' on something that doesn't bring in revenue. How many typical companies are growing their security teams currently, or for that matter employing people who are dedicated to nothing but security?
Security is still not part of 'doing business as usual' in the minds of most companies. When convenient, it is listed as a supplemental bullet point in their considerations, but never is it part of their primary decision. This extends from how they design and protect their networks to the desktop products they purchase. Internet Explorer comes with their Windows desktop, so it's the standard, regardless how filthy it's track record is.
Those companies that are taking security seriously, that are working to make it part of the mentality, are going to be finding that closed source operating systems cannot provide the same level of configurability and security as the open operating systems. Take a BSD or Linux machine and you can audit or change absolutely anything you wish. You can always investigate any worry you have. Think the vendor has left themselves a back door? Check the source. Think that something isn't working properly, or the documentation is not accurate? Check the source. Found a bug but the vendor isn't getting around to fixing it fast enough? You have the source for everything, and you can make any change you want.
This ultimate configurability allows you control over every aspect of your systems, and cannot be paralleled by closed source environments. Security conscious environments will be drawn toward open source systems. And for general business reasons open software is appealing. When you have the entire code base for your software, no vendor can manipulate you into licensing fees and costly upgrades. Your software could be desupported by the creator, just as occurs with proprietary software, but you have the code so you can keep it functioning without any vendor assistance. You can't be locked out of code that you possess that is under one of the Open Source compatible licenses, such as the GPL or BSD licenses.
Of course, that last point is important - just having the source is not sufficient if you do not have the rights to do what you want with it. Some companies are making code source available in limited cases with extremely restrictive licenses. Having the source is not enough - you must have the ability to modify and rebuild from the source. Don't get suckered into anything less.
I believe in full disclosure when done in a responsible manner. If someone finds a bug in a software product, they should not go blabbing it to the world, they should contact the maintainers of that software, be it open or closed source, to get the problem fixed. Having exploits out in the wild before the maintainer can provide a patch does not help the security of our environment. There are several disclosure policies available that provide suggested timelines for working with a vendor before going public. My preference is still for Rain Forest Puppy's RFPolicy, as it provides the correct balance between fixing the problem and forcing the vendor to fix the problem in a timely manner.
I adamantly do not support hiding or denying vulnerabilities. The vendor who gets a report about a vulnerability and attempts to convince the researcher to keep quiet is reprehensible. If one person can find a bug, someone else can too, so likely there's a malicious cracker out there that has also discovered the vulnerability and will exploit it until it is fixed. Public disclosure of the vulnerability is often the only way to force the hand of the vendor, to shame them into fixing the problem. It is up to the discoverer to decide when a vendor is not living up to it's obligations and go public with the vulnerability before the vendor has a patch.
So the last facet of this question is this: once a problem has been discovered, and a patch or upgrade made available, should full exploit details be provided to the public? This is one of the main points on which security folks disagree. I believe that there is no reason not to provide sufficient details and/or exploit code to prove the vulnerability. When a vulnerability is known, you need to upgrade, regardless if there is ready-to-run code to exploit it. Providing that code can force the hands of administrators. It also allows administrators to test their patch procedures to verify they were successful, and in this way proof of concept code is actually a beneficial thing. Also, it provides programmers, both security and non-security proficient, a way to learn what programming mistakes can be made and how they can be tested. This benefits everyone by hopefully producing better programmers and code over time.
There are two main places that Linux machines can live: in the server closet and on the desktop. Each has very different needs. My personal theory is that most Linux programmers are more interested in writing things such as web or mail or file servers, where your 'bragging rights' can be how fast and well it does what it needs to do. I know I'd be much more interested in creating a secure network socket between two custom embedded linux devices than creating a friendly gui user interface. I'd not be at all qualified for the latter. My normal usage involves 15 text TTYs, most running screen, and use of X11 only when I need to visit websites that require JavaScript.
However I'm extremely glad there are programmers out there who have the desire and abilities to create the software that will be needed to make Linux a solid desktop operating system -- easy to use window managers, word processors, spread sheets, and the like. Unfortunately, that still leaves a lot of products we don't have covered. We don't have the specialty software, such as billing systems, payment processing, and other products that you need for the accounting departments for example. Some of these can be run natively under WINE/WINEX/Crossover or virtual machines such as VMWare. However the more things you run in emulation, the less appealing Linux is and the more ammunition closed minded managers and IT folk will have to prevent the switch to Linux.
The problem is that creating these tools takes time and manpower. I think in the future we will see more companies providing programmers to open source projects - those companies will see the features they need implemented first, and yet still get a global set of testers and users to find bugs - but this is a change in business operations that will take a bit of time to sink in. But the result will be a global situation in which companies all benefit and have control of their environment. No more vendor lock in, closed document formats, or forced upgrades. Life will be good.
Linux is already ready for prime time in any server closet. You can get a Linux box to be your firewall, mail server, file server, web server, anything that involves the word 'server' quickly, easily, and securely. Most Linux distributions configure their software to be secure in their default configurations. (Those that do not are at least trending that way over time.) Since Linux processes are discreet and isolated, unable to clobber or adversely affect each other without setting up such methods ahead of time, you have more innate stability. Should your mail server process die, it wouldn't hurt your webserver at all. No GUI is required to configure your server software, so you can make configuration changes from your desk, from your home, or on a wireless network at Starbucks. Linux has enough server software to replace almost anything in any organisation today. While replacing legacy servers with Linux may be scary or unnecessary, new installations that use Linux invariably are more manageable and scalable.
I've got a book or two in my head, and should I ever have time to get them down on paper, and I have a Linux security project that I can't yet talk about that would be extremely fun for me and useful to the community that will hopefully begin soon. I also have a number of Stunnel (SSL wrapper) features and patches in my head I want to get integrated into the default code base.
However the most visible project for the next 9 months will be the development of a new child process that my fiancee and I have forked. The expected release date is late February, but things may fluctuate two weeks in either direction. We'll be adding this to our current ptree listing which contains one leaf process Reegen (currently version 3.0). Ahh, life is good being a $PPID.
Add comment
Email to a Friend
